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Abstract 



In today's networked environments, the geospatial value chain is growing more complex. New web 
services and digital media are opening a window of new web based business models. In this 
environment, geospatial data can be easily shared copied, used and reused as well as redistributed 
across the geospatial value chain. That limits the ability of providers to control the flow of their 
intellectual property downstream in the value chain. Same forces affecting geospatial data industries 
have previously influenced other digital media industries for which digital rights management 
emerged as means for providers to control the flow of their intellectual property. Geospatial digital 
rights management (GeoDRM) is a novel topic that lacks formal literature. This makes the definition 
and understanding of the basic components of GeoDRM an essential part of this research. 

A major component of the GeoDRM is digital licenses. Thus, the fundamental research problem is the 
expression of rights on geospatial assets to enable the construction of digital geospatial licenses, 
specifically the problem of licensing vector datasets manifested in GML format is tackled as a step 
towards an integrated licensing framework for digital geospatial assets. 

This research was conducted on three main phases. Phase I was dedicated to understanding the field 
of GeoDRM. We have realized that GeoDRM consists of both legal and technology aspects. Any 
GeoDRM implementation is a combination of legal and technical measures acting together to form a 
GeoDRM policy for the organization. Separation between the two aspects in implementations would 
result in inefficient GeoDRM policies that either relies too much on technology where it's not needed 
or would rely too much on legal measures where it's not effective. We then defined GeoDRM by 
means of a modified GeoDRM spectrum to reflect the different components of GeoDRM. In phase II 
of the research we have conducted the technical analysis of digital rights management technology and 
have derived the GeoDRM reference architecture. We have also proposed a GeoDRM information 
model. At the end of this phase we provided a model for the Geospatial License (GeoLicense) and a 
general requirements list to extend a rights expression language to construct licenses for GML data 
assets. 

In the third and last phase of this research, we have provided an implementation of the Geolicense by 
extending a digital rights language (ODRL) to accommodate the Geolicnese requirements for the 
GML data assets. The approach is based on using the GML vocabulary within the rights language data 
dictionary to construct spatial data types and provide spatial extension of the ODRL language. We 
then provided a proof of concept by building licenses of three scenarios based on Ordnance survey 
licenses. Due to the lack of GeoDRM technology implementations, we have developed the schema 
and proof of concept using the XML development IDE Altova XMLSpy. 

A major conclusion of this research is that rights expression languages are a powerful tool for 
expression contractual agreements. We have adopted it to the geospatial domain on GML data assets. 
Further research needs to be done to better assess the technology and to deepen the understanding of 
the GeoDRM over all requirements. 
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Glossary of Terms 



Asset 

An Asset is defined in the Webster dictionary as "an item of value owned". In the realm of Service 
Oriented Architecture (SOA), an organization can own the rights to a service rather than digital 
content. In this sense an asset refers to both digital content and services. 
Digital License 

A computer interpretable contractual agreement that acts as a unit of aggregation of rights granted 

from a licensor to a licensee over an asset. 

DOI 

Digital Object Identifier is a standard for online content identification and linking based on URI and 
URN governed by the International DOI Foundation. 
DRM 

Digital Rights Management, a technology that facilitates the persistent authorized use of digitally 

delivered assets. 

GeoDRM 

Geospatial digital rights management. It can be defined as a set of technologies and legal frameworks 
that are fit to a certain organizational need, forming a GeoDRM policy for enabling rights managed 
geospatial networks (e.g. SDIs) where all rights over geospatial assets are specified by the licensors. 
Any licensee would be "trusted" to honor the licensors conditions within and beyond the network's 
trusted environment. 
GeoLicense 

A digital license describing a contractual agreement between parties over a geospatial asset. 
GML 

Geography Markup Language is an XML vocabulary for encoding geographic information in order to 
be stored and transported over the web. Developed by the Open Geospatial Consortium OGC. And is 
currently being certified as ISO 19136. 
IPR 

Are statuary rights that cover any work that conforms to the requirements of a minimum amount of 
creativity, and provide a means by which the creator can control the copying and distribution of his 
work and gain income and recognition for it. 
ISO REL 21000-5 

A Rights expression language derived from XrML. 
License 

A formal contractual agreement setting out the terms and conditions under which a licensee may 
receive and use data, information and other material supplied to him/her by a licensor, who may not 
necessarily be the owner. 
REL 

Rights Expression Language, A from of policy specification language where the focus of the language 
is on expressing and transferring rights from one party to another in a machine interpretable format. 
ODRL 

Open Digital Rights Language, provides vocabulary and data dictionary for the expression of digital 

contractual agreements. 

PKI 



viii 



Are sets of servers, software, protocols and application programs used to manage the private keys and 
public keys of a group of users (Keys cryptography mechanisms used to encrypt or to digitally sign 
digital resources to ensure authenticity of the resources). 
XML 

Extensible markup language developed by the W3C and is a derivative of SGML. It allows for 
building structured documents enabling the definition, transmission, validation, and interpretation of 
data between applications and between organizations. 
XML Schema or XSD 

A language for specifying the models that describe the structure of information within XML 

documents. 

XrML 

Extensible Rights Markup Language, a REL developed by contentGuard and is widely adopted in the 

DRM domain. 

WFS 

Web Feature Service, It can serve vector datasets to users over the web. It connects at the backend 
with Vector datasets in a myriad of formats. These vector datasets are then converted into GML 
(Geography Mark up Language) and transported to users over the web. 
WMS 

Web Map Service which is developed by OGC, is the production of spatially referenced data 
dynamically from geographic information over the Web. The map itself is an actual portrayal of 
geographic information presented as a digital image file for display on a computer. WMS maps are in 
picture formats such as PNG, GIF or JPEG, or as Scalable Vector Graphics SVGWeb Map Server 
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GEOSPATIAL DIGITAL RIGHTS MANAGEMENT 



1. Introduction, Problem Statement 
and Research Methodology 

1.1. Introduction and Motivation 

In late 1980s and early 1990s content providers, technology firms, government organizations and 
policymakers were confronting the effects of ubiquitous computing networks on the availability and 
dissemination of digital content many of which happens to be copyrighted. Ease of dissemination of 
digital geospatial content started posing threats to intellectual property rights (IPR). As technology 
pushes various industries into the digital frontier many types of content are becoming solely available 
in digital formats, Geospatial data is no exception to this technology force. A Map that is copyright 
protected and sold in paper sheets is now available in digital format for a variety of users and devices, 
from car navigation systems, handhelds, and mobile phones all the way to datasets running under the 
skin of corporate applications and enabling business related geospatial functions. Digital geospatial 
datasets moving across computer networks can be easily copied transformed or incorporated into new 
value add products and services. Geospatial data producers and owners are faced with the challenge of 
controlling the dissemination of their IPR on digital geospatial content downstream in the geospatial 
value chain. 

In (Onsrud, et al. 1998) Harlan Onsrud argues that such environment is not only driven by the desire 
for monetary gain. Rather, the recognition due to authors and moral rights associated with the use of 
spatial data are important issues to encourage the establishment of the public geo-information 
commons. In a geospatial web-services environment with ubiquitous dissemination of digital datasets, 
parties engaging in data sharing activities (e.g. producers and consumers) need the recognition same 
way as book authors need to be cited when there books are used in other works. Such environment 
gives more incentives to producers to publish or otherwise make Geospatial data easily accessible and 
available. 

Digital rights management (DRM) is a popular term for a field that came into being in the mid-1990s, 
two basic definitions of DRM exist: a narrow one and a broader one. DRM solutions originally 
evolved in the media industry where digital delivery of content is quickly gaining popularity and 
where IPR infringement is a serious and direct threat to the current business models. The narrower 
definition of DRM focuses on persistent protection of digital content. DRM provides an automated 
system that will consistently and rigorously enforce agreements made among users, providers, and 
distributors. It allows the distributor of data to control how data is used, and by whom, in accordance 
with rules and agreements in compliance with a given business model and/or IPR schemas. While the 
broader definition of DRM encompasses everything that can be done to define, manage, and track 
rights to digital content. In addition to persistent protection, this definition includes the following 
elements(Rosenblatt, and Dykstra, 2003): 
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• Business rights (a/k/a contract rights): an item of content can have rights associated with it by 
contract, such as an author's rights to a magazine article or a musician's rights to a song 
recording. Such rights are often very complex and have financial terms attached to them that 
depend on the content's use (e.g. royalties). 

• Access tracking: DRM solutions in the broader sense can be capable of tracking access to and 
usage operations on content. Information about usage is often inherently valuable to content 
providers, even if they do not charge for the usage of content. 

Recently higher awareness of the IPR problems within the geospatial domain gave rise to a discussion 
of the challenges surrounding the management and dissemination of IPR. In (Onsrud et ai, 2004) 
DRM is briefly addressed as a suggested solution for the management of geospatial IPR. Other 
researchers (Vowles, and Mckee, 2005) proposed a Geospatial DRM vision for public geospatial data 
libraries and geospatial marketplaces. Recently OGC (Open Geospaqtial Consortium) formed a 
GeoDRM working group (OGC GeoDRM-WG) with the mission statement of adopting the work done 
in the area of data ownership and digital rights management to the geospatial community. The Group 
addresses the lack of geospatial digital rights management (GeoDRM) capability as a barrier to wider 
adoption of Web based geospatial technologies. At this stage by using the term GeoDRM we pertain 
to the General definition stemming from DRM. GeoDRM is the means for management of IPR in the 
digital web-based geospatial data sharing environment. Later in this thesis we develop a more formal 
definition of GeoDRM. 



In web environments, services are employed to deliver geosaptial datasets to users. Figure 1-1 below 
illustrates an example of web services which is the WFS (OGC 2002-WFS) The WFS is the Web 
Feature Service. It can serve datasets to users over the web. It connects at the backend with Vector 
datasets in a myriad of formats. WFSs can be cascaded which means a WFS can use another WFS as a 
datasource. The vector datasets on the WFS backend are converted into Geography Markup Language 
(OGC 2005-GML) and served to users. GML is an XML-based language for encoding geographic 
information in order to be stored and transported over the Internet. GML was Developed by the OGC 
and is currently being standardized as ISO-19136, GML defines both the geometry and properties of 
objects that comprise geographic information. 



1.2. 



Context of the Research Problem 




Figure 1-1 Geospatial Web services configurations 
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Geospatial data poses unusual problems for the protection of IPR. Among these problems are the 
variety of formats in which geospatial data is delivered and the variety of services such as analysis 
web-services or OGC web-services mentioned above. 

The two challenges are a major drive behind DRM for the Geospatial domain 

• In The DRM domain there is variability in data formats (multimedia formats), however 
content is always disseminated, as discreet units for example a book is not part of a whole, a 
book in that sense is a standalone discreet unit. While in figure 1-1 a GML dataset sent to a 
user and is covering a district is part of a larger whole that is the entire city. 

• Also in figure 1-1 a typical use of geospatial data also involves cascading information from 
multiple data sets and integrating them to create a new data set like, entering gray areas of 
mixed and sometimes conflicting IPR. It is therefore necessary to have detailed terms and 
conditions for the many aspects of access, use, and dissemination of IPR to protect the 
providers' interests in web based geospatial data sharing. 

At the heart of DRM is digital licensing. Digital licensing is a translation of a contractual agreement 
over IPR between interested parties by which one party gives certain rights over an asset to another 
party. Digital licenses are basically computer interpretable units of aggregation of those rights. 
Computer interpretable digital licenses mean that management and enforcement of these licenses can 
be automated. In DRM Rights Expression Languages (RELs) are developed to express digital licenses 
and provide the semantics and vocabulary for formulating complex contractual agreements examples 
of RELs are ODRL (ODRL 2002), and the XrML (XrML 2004) derived languages MPEG-REL and 
ISO21000-5. 

1 .3. Problem Statement 

Geospatial data can be distributed in analogue form (e.g., hardcopy maps) or they can be distributed in 
digital form through web services as part of a SDI or business networks. The later poses serious 
implications on the ability of geospatial content providers to manage their IPR downstream in the 
value chain and hence hamper social and economic progress in developed and developing countries 
alike. Data providers want to be able to offer their digital geospatial data in a way that guarantees the 
protection, recognition and honoring of their intellectual property against any use that does not 
conform to their specific contractual agreements. GeoDRM as a novel topic lack formal definitions 
and literature. This research aims as a step towards a full-fledged GeoDRM framework by identifying 
GeoDRM architecture and the general GeoDRM components. A major component of the GeoDRM is 
digital licenses. Thus, the fundamental research problem is the expression of rights on geospatial 
assets to enable the construction of digital geospatial licenses, specifically the problem of licensing 
vector datasets manifested in GML format needs to be resolved as a step towards an integrated 
licensing framework for all digital geospatial assets. 

1.4. Main Objective 

• To identify an appropriate method to describe contractual agreements for licensing of 
geospatial digital content via a rights expression language and develop an extension to an 
existing licensing standard as a proof of concept 
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1.4.1. Sub Objectives 

1. Define the elements of GeoDRM framework. 

2. To develop a high-level architecture for GeoDRM digital licensing. 

3. Define a General GeoDRM Information model. 

1 .4.2. Research questions 

1. What is DRM and how is it different from seemingly similar fields like access control? 

2. How are Geospatial Intellectual property rights currently being disseminated? 

3. Why GeoDRM is needed in today's geospatial data sharing environments? 

4. how can we define GeoDRM more formally, What is the Formal definition and scope of 
GeoDRM? 

5. How digital licensing of assets is managed on web environments? 

6. What are the components of the GeoDRM architecture? 

7. How can we develop a GeoDRM information model and what are the components of the 
GeoDRM information model? 

8. What are the general requirements of geospatial rights expression on GML datasets? 

9. How do we accommodate the above requirements in existing Rights expression languages? 
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1.5. 



Research Design and Flow 



In this research we have conducted the approach depicted in Figure 1-2. The research was divided into 
three phases. In the following sections each of the research phases are highlighted with a more 
detailed explanation. 
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1 .5.1 . Phase I GeoDRM Definition 

In the first phase we approach the GeoDRM problem with the intention to set the foundation for 
understanding the GeoDRM field and to position this research within the larger picture of GeoDRM. 
To achieve this we study current DRM definitions and define the relation between DRM and another 
common field which is access control. Stemming from this part we adopt a wider definition of DRM. 
We then study the relationship between IPR law and contract law (licensing) and reflect the finding 
on GeoDRM. This assists in establishing the case for GeoDRM through examining GeoDRM related 
activity in some organization where relevant activity is taking place. At the end of this phase we 
define GeoDRM and set the scope of this research within the larger picture of GeoDRM. 

The main output of this phase is: 

• Identifying and understanding the two major aspects of a GeoDRM policy (legal aspects, and 
technical aspects). 

• A formal definition of GeoDRM to guide the development of this research. 

1.5.2. Phase II: GeoDRM architecture & Information Model 

In this phase we study the technical aspects of GeoDRM. We approach the research problem from a 
DRM digital licensing perspective. We address the DRM reference architecture and modern DRM 
licensing infrastructure to derive the GeoDRM reference architecture that is capable of managing 
digital licensing in web environments. Utilizing literature study of the elements of information within 
DRM digital licensing infrastructures we derive the GeoDRM information model where we focus on 
rights information as an essential element for our research. By feeding the information derived from 
the GeoDRM reference architecture and the information model along with additional study elements 
we identify the requirements for the geospatial rights expression. As a final stage we derive the 
geospatial license (geolicense) model. 

The main output of this phase is: 

• The GeoDRM reference architecture 

• The GeoDRM information model 

• The Geolicense requirements and model. 

1.5.3. Phase III: Geolicensing Proof of Concept 

In phase III we address the extension of Open Digital Rights Language to enable the expression of the 
geolicenses on GML data. We illustrate the methodology followed to derive geospatial capabilities to 
ODRL to build the "GeoREL" this methodology can then be applied to any other REL to achieve 
similar functionality. In the same phase, we provide a proof of concept for the developed GeoREL 
schema by implementing licenses on a sample GML dataset. The licensing scenarios are derived from 
Ordnance survey Print/Copy shop license. Due to lack of GeoDRM technology implementation at the 
time of writing this thesis, we have used Altova XMLspy IDE (Integrated software development 
environment) to validate the syntax and type checking of the developed schema as well as to validate 
the licenses against the developed GeoREL schema. 

The main output of this phase is: 

• GeoREL XML schema 
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• Sample licensing on a sample GML dataset depicting the proof of concept. 

1.6. Research Contribution 

• Proposed high level architecture and reference information model and Geolicense model. 

• Proposed Extension of Rights Expression Language (REL) to support GML datasets. 

• Proof of concept implementation for the Extended REL on a sample GML dataset using a 
licensing scenario based on Ordnance Survey Print/Copy shop license. 
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2. 



Definition of GeoDRM 



2.1. 



Introduction 



Geospatial DRM (GeoDRM) is a novel topic with very few supporting literature, hence at the start of 
this research there was a lack of understanding of the scope and purpose of GeoDRM. An initial step 
for this research was to understand the basic components of DRM and reflect that on the geospatial 
domain to define GeoDRM. This would then enable us to scope this research within the bigger picture 
of GeoDRM. 

DRM and consequently GeoDRM deal with Intellectual property rights (IPR) thus; it is important to 
consider that services provided by DRM technologies are governed by legal, cultural, and social 
constraints pertaining to IPR laws and regulations. Therefore, it is important to develop a basic 
understanding of these aspects and their effects on DRM. In DRM Rights can be viewed as acts which 
users are entitled to over certain assets. This spans all acts that access, modify, merge, or duplicate 
any content also; it includes terms of use for online services and other assets. DRM consists of both 
technical and legal frameworks, the understanding of both is essential to build DRM policies that 
meet requirements of a specific situation. GeoDRM would also consist of a technical and a policy 
framework. 

In section 2.2, we define access control from a critical point of view as opposed to DRM, which puts 
DRM in a more clear perspective. The goal of 2.5 is to establish the definition of DRM, that would 
later contribute to a wider understanding of the domian. In section 2.4, we discuss the legal aspects 
surrounding DRM in general and the implications of these aspects on GeoDRM in particular. In 
section 2.5 we address the case for GeoDRM by examining current approaches within the vision for a 
Geospatial marketplace, the INSPIRE initiative, Ordnance Survey MasterMap and Open Geospatial 
Consortium. Section 2.6 combines the conclusions derived from the previous sections into a common 
understanding of GeoDRM and then the chapter is concluded in 2.7 by scoping this research within 
the larger picture of GeoDRM. 



In today's network-connected, highly dynamic, and distributed computing environments, digital 
information is likely to be used and stored at various locations and therefore has to be protected. In 
highly distributed systems where identity of subjects is usually unknown and the location at which the 
digital content is used is not constant, authorization cannot be determined from an authorization 
database. Instead, authorization is granted to trusted parties using public -private key infrastructure. 
Public Key Infrastructures (PKI) are sets of servers, software, protocols and application programs 
used to manage the private keys and public keys of a group of users (Keys are cryptography 
mechanisms used to encrypt or to digitally sign digital resources to ensure authenticity of the 
resources). A user uses his private key to encrypt his content, and distributes his public key to others 
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who are interested in decrypting the content. Users are generally able to create and update their own 
key pairs, and a Certificate Authority is used to sign new Public Key's (Sandhu, and Samarati, 1994). 
In recent years, research in authorizations has been pursued under the name of trust management. 
Both traditional access controls and trust management deal with the protection of digital resources 
within the trusted environment of a resource provider (Park, and Sandhu, 2004). None of these 
systems deals with protection of resources on the client machine outside the trusted environment of 
the provider. (Schneck, 1999) introduced a new perspective on access control problems considering 
requirement for persistent access control, in the sense that protection of any digital resource occurs 
wherever this resource exits (e.g. on a server or when content is moved to a client environment). (Park 
et al., 2004) showed the difficulty of achieving this on a large-scale distributed environment and 
proposes usage control as an extension to access control. Modern DRM in many aspects is a reflection 
of the usage control. In the next section, we address the definition of DRM. 

2.3. The Definition of DRM 

Recently the term Digital Rights Management (DRM) emerged focusing on controlling Intellectual 
property rights of already disseminated digital content (i.e. how rights holders have agreed there 
content should be used) .Many definitions of DRM are offered by researchers. (Liu, Sheppard, 2003) 
defines DRM as a system to protect high-value digital assets and control the distribution and usage of 
those digital assets. (Rosenblatt, Trippe, and Mooney, 2002) has a more general definition where he 
defines DRM as a system where its ultimate goal is to make mass copying and distributions difficult. 
In this definition, Rosenblatt refers to illegal mass copying, use, reuse and distribution of digital assets 
that is becoming more common place in the networked environments, and the role of DRM is to make 
mass copying unlikely to appear. 

Another widely accepted definition of Digital Rights Management is "The ultimate goal of a 
distributed DRM system is for content authors to be able to project policies governing their assets use 
into remote environments with confidence that those policies will be respected by the remote 
nodes "(Lamacchia, 2002). Digital content providers need to be able to project their policies on assets 
to be enforceable regardless of the location of the assets. This last requirement highlights the need to 
express rights persistently and couple them with the digital resources as they move on the network. 

The above definitions rather stem from content background (i.e. as opposed to services) because 
current DRM solutions have been largely driven by commercial media industries and are mainly 
focused on intellectual property rights (IPR) protection of content, (Park et al, 2004) and (Rosenblatt 
et al, 2002). In this research, we adopt the following definition which focuses more on technologies 
to manage rights. (Contentguard, 2001), (Park et al, 2004) define DRM as technology that facilitates 
the persistent authorized use of digitally delivered assets. This definition extends Digital Rights 
Management to include all rights, from intellectual property rights to all usage rights and access rights 
for services and digital resources in the broadest sense all within a distributed network environment. 

Since DRM aspires for the management of rights over digital asset. In this research, we adopt a 
certain definition of the term Asset. An asset is defined in the Webster dictionary as "an item of value 
owned". In the realm of Service Oriented Architecture (SOA), an organization can own the rights to a 
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service rather than digital content. Hence, services may also earn the attribute of being of value. In 
this sense, we use the term asset to refer to both digital content and services. 

By a service, we mean a web service that are self-contained, self -describing, modular applications that 
can be published, located, and invoked across the Web. Web services perform functions, which can be 
anything from simple requests to complicated business processes, once a Web service is deployed, 
other applications (and other Web services) can discover and invoke the deployed service. Geospatial 
web services are web services that have geospatial functionality like data analysis for example. Since 
web services are exposed over the web, it is important to ensure security of the web services. 
Prominent DRM technologies like ISO REL, XrML and ODRL are being further exploited by the 
technology developers; XrML is being used to control rights of use of Web Services(Contentguard, 
2001). For example, a geospatial web service may provide the user with the ability to do 
generalization of his datasets. For this user to be able to use the service he must prove he has the 
essential rights to execute the service. RELs can be used to describe the user rights over this service in 
an access ticket form. The user then has to supply the license to the service to be granted authorization 
to use the service and do the generalization. 

It is important to note that the definition adopted above closely relates DRM with access control from 
a technical perspective at a certain level of abstraction. This observation was also confirmed by 
(Lamacchia, 2002) and (Park et ai, 2004) who argue that there is a significant unity between DRM 
and the access control fields. We can assert here that DRM can be used to manage all rights on digital 
assets. From above these rights include two distinct categories (Lamacchia, 2002), (Park et ai, 
2004),(Contentguard, 2001): 

• Intellectual property rights (Licenses) where licenses are defined as formal agreements setting 
out the terms and conditions under which a licensee may receive and/or use assets, 
information and other material supplied to him/her by a licensor, who may not necessarily be 
the owner. 

• Service usage rights (includes access rights) 

However, despite the technical similarity at some levels between DRM and Access control they 
remain fundamentally different. The fact that DRM stems from IPR background has more profound 
effects on the understanding of DRM, We assert that the major difference between DRM and access 
control lies in the fact that DRM has to be supported by a legal framework. While organizations might 
have access control policies, these policies are not legally binding. It is simply means to state which 
parties can access which resources. In DRM however, policies are legal agreements between parties 
the first place. 

An integral component of DRM systems is digital licenses; a DRM digital license (Figure 2-1) has the 
same legal meaning as a legal contractual agreement and acts as its digital equivalent to aggregate the 
terms and conditions of the agreement in a computer interpretable format. It is of utmost importance 
to recognize the fact that DRM is simply means of managing and reflecting actual legal agreements 
onto the digital environment. 
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License 



Licensee: Douglas Adams 



Rights 

Print (5 times, 3 chapters only) 
View (all) 
Copy (Once) 



Asset America (The Book): A 
Citizen's Guide to Democracy 
Inaction. sbx 



Issuer: Frank Zappa 




Figure2-1 A Simple view of a DRM license 



In the next section, we address the DRM policy framework to understand the policy aspects 
surrounding DRM. 

2.4. The DRM Policy Framework 

As we established in the previous section, DRM consists of a policy and a technical framework. 
(Duncan, et al. 2004) identify the following general DRM stages in the formation of DRM policies. 
These stages are not mandatory. Not all the stages have to be fulfilled but the stages are the logical 
steps to the realization of a full-fledged DRM policy. 



Assertion of rights 



Expression of rights 



Dissemination of rights 



Exposure of rights 



Enforcement of rights 



Rights policy 
Creation 



Rights policy 
Projection 



Figure 2-2 Stages of Realization of DRM 

Rights Policy Creation: 

a. Assertion of Rights: is provided by a legal framework in which people and organizations can 
assert their rights in a form that is defendable under law. Several license models are emerging, 
(e.g. creative commons and open source licenses which are licensing schemas that belong to 
the "Copyleft" movement, which intends to reduce the restrictions imposed by IPR law on the 
usage of assets). 



b. Expression of Rights: has traditionally involved only a copyright statement in a human- 
readable form. While this is still important it is also essential to take into account machine-to- 
machine (m2m) communication when considering the expression of rights for DRM, hence 
legal licensing terminology needs to be simplified and streamlined. 
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Rights Policy Projection 

a. Dissemination of Rights: ensures that whenever an asset is described, its rights are also 
described. This is the first stage in enforcing the DRM Policy. It requires that when asset 
hubs, catalogues, or portals gather metadata they also gather rights metadata hence rights 
holders are confident that assets are always coupled with rights metadata. 

b. Exposure of Rights: is the stage at which users view rights information associated with 
assets. This will often be when searching for assets. If there are differences between the 
permitted uses for different assets then these should be easily apparent without detailed 
scrutiny of license conditions. The semantics of terms used in a license must be unambiguous 
and well understood by subjects using the assets so that understanding and projecting rights 
information is effective and accurate. 

c. Enforcement of Rights: includes protective measures to ensure that rights are not infringed 
and steps to be taken when infringements are detected as well as legislation for the protection 
of the technical measures taken. 

The subsequent two sections we will introduce two major aspects which demonstrate the policy 
requirements that should be taken into consideration when designing a DRM system. The first aspect 
is the EU directives which are considered a high set of policies that are meant to guide and support 
DRM policy makers by providing legal protection for DRM implementations and legal protection for 
database rights. The second aspect is the relation between IPR law and Contractual agreements which 
reflects on DRM 

2.4.1 . EU directives on DRM and Database copyrights 

Directive 2001/29/EC of the European Parliament and of the Council of 22 May 2001 on the 
harmonization of certain aspects of copyright and related rights in the information society has 
provided legal ground for the digital management of rights (DRM) by providing anti-circumvention 
law for DRM technology. This directive is equivalent to the US digital millennium copyright act. 

Another directive would have profound effect on the dissemination of Digital Geospatial Datasets is 
DIRECTIVE 96/9/EC which is pioneered by the EU and is leading the change around the world. 
DIRECTIVE 96/9/EC Database Directive established an entirely new intellectual property right, 
called a "sui generis" right (from the Latin "of its own kind"). This right takes its place next to other 
IPR rights of trademark, copyright, and patent. Under the Directive, database makers can, for a period 
of 15 years from the completion of the database, prevent unauthorized extraction and reutilization of 
the contents of the database. 

A database which will benefit from the sui generis right is described as "a collection of independent 
works, data, or materials arranged in a systematic or methodical way and individually accessible by 
electronic or other means." Databases may include any type of information, such as text, sound, 
images, numbers, facts, or raw data. It is for this reason that commentators have also referred to the 
Directive as the "Multimedia Directive." Electronic and print databases are covered. Many geospatial 
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datasets are provided as relational databases and this new IPR provides new strength for protection of 
rights on geospatial databases. 

Both directives 96/9/EC and 2001/29/EC provide solid grounding for DRM as the means for 
management of IPR and ultimately for GeoDRM as means of Geospatial IPR management via two 
layers of legal frameworks: 

• The first directive provides legal protection against circumvention of DRM technology (e.g. 
decoupling an asset from its digital license), hence DRM implementations are protected 
against illegal attempts to isolate the manage assets from the rights managed environment. 

• In addition, the later directive extends IPR law to be explicit on databases in general. 

The first point above is an essential measure to make DRM solutions feasible for the management of 
IPR, by imposing legal measure to prevent any tampering with the solutions and covers both policy 
projection aspects and policy enforcement. Consequently, this directive covers any geospatial solution 
for management of geospatial IPR within the GeoDRM framework. The second point provides IPR 
law coverage for all databases including geospatial databases. This in turn indicates a challenge facing 
GeoDRM policy makers as to how to strike a balance between statutory rights and contractual rights 
which we will illustrate the implications of in the next section by defining the formal relation between 
statutory rights and Contractual rights (licensing). 

2.4.2. Statutory Rights Vs Licence Rights in the Geospatial Domain 

Intellectual Property Rights (IPR) traditionally covers four main rights (Figure 2-3): copyright, patent, 
design, and trademarks. Other rights have recently emerged such as the Database rights (Sui genreis 
rights, as discussed above). 



Generally, IPR are statuary rights that cover any work that conforms to the requirements of a 
minimum amount of creativity. It provides means by which the creator can control the copying and 
distribution of his work and gain income and recognition for it. This recognition constitutes the 
component of the implicit moral rights within the IPR law. This in turn assures creators that even 
when their creations are lawfully used it has to be used appropriately and in a manner, that shows 
respect to them. Copyright is binding to a buyer of a book automatically by committing the transaction 
of buying a book. Licensing on the other hand, requires a contractual agreement which both parties 
establish together. Current rights management systems don't directly map to current copyright laws, 
the reasons being that the user's Intellectual property rights are a result of the reconciliation of two 
different and sometimes conflicting rulings (Chong, 2005): 

• Statutory rights granted by the IPR law in each country (e.g. copyright, Sui generis). 



Moral 
Rights 




V 

Figure 2-3 Bundle of IPR law rights 
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• Rights permitted by the rights holder (e.g. author or digital library) to a user through 
licensing. 

The IPR laws and in particular the copyright law depended heavily on the notion of "copying" as the 
major source of infringement of IPR. Copying in the digital world however, is not a good predictor of 
intent to infringe. Copying of digital works is sometimes necessary for normal use of those works. In 
place of the right to copy, the right to control public distribution and uses of the copyrighted work 
through digital licensing might gradually replace ordinary copyright laws (Miller, and Feigenbaum, 
2002). In summary, the following two observations are important: 

• Licenses do not relinquish the IPR granted by the law unless explicitly stated in the license 
terms 

• The relationship between licensing and IPR law needs to be addressed while setting licensing 
policies for DRM. This will enable us to avoid potential conflicts between statutory rights and 
licensed rights. 

The dissemination of IPR on geospatial content is mainly done via licensing. It is noted that 
researchers acknowledge that licensing of geographic data and works has come of age mainly because 
of the limited protection afforded by copyright and other intellectual property doctrines in the digital 
environment (Onsrud et al, 2004). According to the reasons, licensing has become commonplace can 
be summarized as: 

• The realization that many geographic data, as opposed to geographic creative works, are 
difficult to protect through copyright alone 

• A shift away from supplying distinct datasets to providing access to databases which means 
each distinct part downloaded has potentially different license agreement. 

• Increased concern over potential liability and a desire to limit liability through explicit license 
systems. 

• The rise of shared cost and data maintenance partnerships means that various parties can 
assume IPR ownership on various aspects of the same dataset. 

• Developments in network technology and digital geospatial datasets have been accompanied 
by increased use of licensing as an alternative to the outright sale of the data and data 
products a trend that is similar with other content types. 

Licensing of geospatial assets means a transaction or arrangement (usually a contract, including 
maybe an exchange of value) in which the acquiring party (i.e. the licensee) obtains information with 
restrictions on the licensee's rights to use or transfer the information. Examples of such restrictions 
include: 

• Limits on the persons or entities (such as other agencies or the public) to whom the 
information may be disclosed. 

• Limits on the purposes for which the information may be used. 

• Limits on the duration of the license. 

• Limits on ability of a licensee to delegate licenses to other parties, and provisions regarding 
ownership and use of products developed through the use of the licensed information. 
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In Figure 2-4, we conclude the above section by illustrating the relation between IPR Law and 
Contract law and the abstract role of GeoDRM as follows: 

• Intellectual property rights can be managed in two distinct ways, IPR law and licensing. The 
shifting towards licensing is synonymous with the advent of digital datasets and online 
dissemination of the geospatial assets. 

• Licensing can provide wider (copyleft) or narrower freedoms than is granted by the IPR law. 
If GeoDRM policies are not crafted properly, conflicts may arise between statutory laws such 
as copyright and Sui genereis rights. Hence, the GeoDRM policy framework must consider 
these issues. 

Intellectual Property Rights 



mination of the Digital Geospatial Content- 



IPR Law 

copyright, patent, design and 
trademarks. Other Rights (sui generis) 



Inadequacy of the 
copy right law in ( V 
digital environment 




More Freedom 

E g- CpPY'eft 



Contract Law 

Contractual Agreements, Licensing 





Harmonized Licensing 
Frameworks 


GeoDRM 

Policy Creation 


A Hnw to Manage 
( IP in a digital 
V 1 Environment? 


Policy Projection 
(technical aspects) 



Figure 2-4 relationship between IPR law and Contract law with respect to GeoDRM 



• The shift to contract law requires harmonized licensing frameworks. This would enable 
building less complex GeoDRM service infrastructures to meet the needs of varying 
geospatial stakeholders. 

In this section, we have learned that management if IPR in the digital environment using DRM and 
subsequently GeoDRM needs two layers of supporting legal frameworks. First, there is the legal 
protection of the GeoDRM framework against any infringements or breaches of the technical 
measures applied. Second are the legal contractual agreements that are represented in digital format 
and used to disseminate IPR on geospatial assets. 

2.5. The Case For GeoDRM 

Both developed and developing countries are putting their geospatial data holdings online. However, 
one of the major obstacles for ubiquitous geospatial web services is that data providers lack 
technology to maintain the intellectual property on their assets. Hence GeoDRM is always addressed 
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from the point of view of new business models suited for the online geospatial environments. A 
specific GeoDRM configuration depends on four major aspects (Vowles et ai, 2005): 

• The business of the organization, for example the motivations of commercial public-sector, 
and academic organizations to make their geodata available. 

• The types of data and media formats such as physical, electronic, text, graphic, vector, raster, 
observations etc.. 

• The content distribution channels, size of content, network bandwidth, types of end user 
devices. 

• The types and granularity of intellectual property rights to be protected and the contractual 
obligations for its use. For example license to reuse parts, limited distribution, 
sensitive/classified. 

The complexity of each aspect of the above makes the task of defining GeoDRM as one technology in 
a clear cut definition not a practical matter since different organizations and business models would 
lead to a different understanding of the role and components of GeoDRM. In this section we briefly 
address three different examples to deduce conclusions relevant to the purpose of definition 
GeoDRM. These conclusions are then fed into section 2.6 to define GeoDRM and place this research 
within the wider picture of GeoDRM. 

2.5.1. The Geospatial market place 

As a summery of the vision from the research conducted by the Committee on Licensing Geographic 
Data and Services, National Research Council of the US (Onsrud et ai, 2004). A National 
Marketplace for Geographic Information would provide an online environment where any licensor 
(rights holder), no matter how small could: 

• Efficiently post its offerings in a searchable form using a menu of standard licenses and 
metadata reporting. 

• Would-be purchasers could search through thousands of offerings to find the geographic data 
that meet their technical and license condition needs. 

• In the simplest implementation of the marketplace, purchasers would obtain the data directly 
from the vendor after "clicking through" to contact its server. 

• Minimal investment could provide a combined license and metadata creation capability for 
sellers and search capability for consumers within a short time. 

• In more advanced implementations, the licensor might define detailed digital licenses or sale 
conditions tied to defined pricing formulas and participate in automated financial transactions 
and downloading of products. 

• Digital licenses can then be used to track the usage of the vendors IPR as well as for 
automated enforcement of the license terms. 

• Buyers would be able to accomplish efficient comparison-shopping and buy or license desired 
geographic data within minutes of finding it. Licensors accounts could be automatically 
credited with funds from product sales, and sellers would be able to alter their geographic 
data offerings, descriptions, license conditions, and pricing formulas at any time. 

Same model can accommodate geospatial web services for processing or mapping as geospatial assets 
(e.g. WFS) where a license to access and use a certain service is granted by the licensor and a licensee 
can submit the license to any service which would validate the license and enforce the embedded set 
of rights. (Onsrud et ai, 2004) briefly discusses DRM as means of management of rights in the online 
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geospatial marketplace. In this vision, GeoDRM is a central part of the marketplace providing IPR 
management capabilities. 

2.5.2. Providing Geospatial Content Online 

Ordnance Survey (OS) provides many digital Vector as well as Raster data. MasterMap is digital map 
designed by Ordnance Survey for use in advanced GI applications. Based on the National Grid, it 
includes topographic information on every landscape feature. From buildings, roads, phone boxes, 
postboxes, landmarks. MasterMap presents this comprehensive, large scale, advanced information as 
themes in a series of layers, each layer carrying millions of features. Each feature in OS MasterMap 
has its own unique identifier (TOID) which is a 16 digit unique number. This allows easy data 
association and greater accuracy in coupling datasets. Data can be searched online based on many 
criteria which include area, Layer, license period, and number of users. 



Register 


Estimates 


Exit 
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Figure 2-5 Ordnance Survey MasterMap Selecting Map area to be licensed by the tool box to the right 




Figure 2-6 OS selecting licensing Terms and licensed layers or themes 
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Figures 2-5 and 2-6 illustrates the process of purchasing MasterMap data which is highly automated, 
the web site allows users to register and provide their personal information and the intended use of the 
data. 

Users then proceed to define layers, themes, and area of interest as well as additional licensing terms 
(e.g. duration of license, number of users). Once the selection process is done, the user can place an 
order for the dataset or save the session and come back to it later with payment information to place 
an order. The user prior to placing an order must accept a series of click-through licenses. Once the 
order is processed and the delivery medium of the data is selected (CD, DVD, FTP download) the 
user either waits for the delivery of the dataset is case of CD and DVD or can wait 1 day before 
receiving notification that his dataset is ready for download from the FTP. 

OS currently provides click-through license mechanisms (where users click acceptance of licensing 
terms on a computer screen). Click through online licenses enables access to a wide range of official 
information launched by the UK's HMSO (Her Majesty's Stationary Office which is the custodian of 
Crown Copyright, which covers most central government information. Shrink-Wrap is the US 
equivalent of this license. Courts have upheld these licenses and ruled them binding(Onsrud et al., 
2004). OS as a Member of OGC (Open Geospatial Consortium) is a major player in the GeoDRM 
working group (2.5.4). OS intends to establish a technical framework to accommodate OS licensing 
needs based on the GeoDRM framework. Where automated license management would provide OS 
the ability to track, protect and manage the dissemination of IPR downstream in the value chain. 

2.5.3. European INSPIRE initiative and IPR licensing 

The INSPIRE initiative aims at establishing the European SDI to deliver users integrated spatial 
information and services. The first phase of INSPIRE is to focus on environmental policies and then 
extend to other sectors such as agriculture, transport and energy (Inspire, 2005). The initiative 
provides basic geospatial information in 31 initial themes on a European level. These themes 
constitute mostly foundation data provided by the governments of the member states. Initial actions of 
INSPIRE include among others, establishing harmonized licensing frameworks for data access and 
sharing and to establish a clearinghouse network including services for discovery, query, view, 
download and trading of geospatial data. Ultimately, INSPIRE aims at establishing a geospatial 
marketplace, it is expected that that a thriving market for value add services will develop on top of 
public sector spatial data. 

INSPIRE initiative defines a license as a formal agreement setting out the terms and conditions under 
which a licensee may receive and use data, information and other material supplied to him/her by a 
licensor, who may not necessarily be the owner. The initiative identifies the owner of the IP to be the 
center of gravity. Ownership may involve more than one set of rights like moral, authorship, 
commercial, etc (Inspire, 2004). 

The four dimensions of IPR dissemination in INSPIRE (Figure 2-7) are driven by market models (no 
cost, cost recovery, etc..) which lead to a policy framework in which access, permitted usage, 
charging rates, royalties, obligations and responsibilities of the parties must be well defined. 
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Figure 2-7 the control of IPR 



It is essential, therefore, that the policy and legislation takes this into account to ensure that owners 
and rights holders have flexibility to decide or influence the terms and conditions of such information 
sharing and trading(Inspire, 2002). The initiative defined a general policy which we summarize below 
to exemplify regional policies: 



• Clearly define the spatial datasets to which public access is limited and the reasons for such 
limitation. 

• Impose an obligation to supply information for any purpose subject to basic licensing 
arrangements. Type of use directly relates to which type of licensing arrangement was needed. 
Types of use include personal, commercial use and re-use 

• Simplify licensing arrangements for personal use. Propose to use a click-through license notice of 
terms and conditions that is deemed to be accepted. 

• Ensure that the scope of copyright applies uniformly throughout the EU. This is especially 
important in the context of maps and map products. 

• Metadata must be made available and shall include information about rights of use of spatial data. 

The inspire initiative in general stresses on the importance of clear and harmonized licensing 
frameworks for the 31 data themes initially covered by the first proposal. The stress on these 
harmonized licensing frameworks is important to be able to achieve feasible click-through licensing 
mechanisms that are valid across the EU member states. In other parts of the proposal where value 
added products are mentioned licensing takes more commercial approaches that are similar to those 
exhibited in 2.5.1 and 2.5.2 by OS. 

2.5.4. GeoDRM in the Open Geospatial Consortium 

By mid 2004, the OGC (Open Geospatial Consortium) established a GeoDRM working group with the 
mission of coordinating and maturing the development and validation of work being done on digital 
rights management for the geospatial community. The objectives set for the working group are: 

• Enable business models for web-based geospatial services by identifying or developing a 
trusted infrastructure for purchasing and protecting rights to digital content. 

• Guide the development of OGC specifications and best practices recommendations to permit 
the exploitation of mainstream DRM approaches, technologies, and standards wherever 
possible. 

• Test, verify, and mature as necessary the technologies required for GeoDRM including 
electronic commerce and information security. 

• Develop specifications for GeoDRM that build on the OGC technical baseline. 
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Currently a draft GeoDRM reference model is being crafted by the working group. The draft has not 
been released at the time of writing this thesis. During the technical meeting in Bonn, a click through 
licensing mechanism was illustrated for the WMS. This was an initial step for a test bed for GeoDRM 
technologies. (OGC 2002 -WMS). Web Map Service which is developed by OGC is the production of 
spatially referenced maps dynamically from geographic information over the Web. The map itself is 
an actual portrayal of geographic information presented as a digital image file for display on a 
computer. WMS maps are in picture formats such as PNG, GIF, or JPEG, or as Scalable Vector 
Graphics SVG. The explicit statement of the need to capitalize on and exploit mainstream DRM 
approaches, technologies, and standards is among the guiding principals of the working group. 

2.6. GeoDRM Defined 

In the previous sections, we have examined DRM on controlling usage and dissemination of digital 
assets according to some well defined digital license agreements between the involved parties. These 
digital licenses map to legally binding agreements that constitute the legal framework of DRM or the 
policy creation aspects. Assets in as previously discussed can pertain to services or contents. In 
addition, we have established that GeoDRM would have policy aspects pertaining in the first place to 
the contractual agreements as well as technical aspects. We have also concluded that GeoDRM is 
highly dependant on the factors provided in section 2.5 and many different GeoDRM implementations 
will exist depending on these factors hence it's not practical to define GeoDRM as one set of 
technologies or a single policy. 

With this view in mind GeoDRM can be defined as a set of technologies and legal frameworks that 
are fit to a certain organizational need, forming a GeoDRM policy for enabling rights managed 
geospatial networks (e.g. SDIs) where all rights over geospatial assets are specified by the licensors. 
Any licensee would be "trusted" to honor the licensors conditions within and beyond the network's 
trusted environment. Trust in this definition is not synonymous with "enforcement of digital licenses" 
which in turn might or might not be part of a certain GeoDRM framework. In addition, a legally 
binding framework of licenses and licensing policies that are then mapped to digital equivalents must 
support GeoDRM. This makes a GeoDRM license a legal tender that must be respected. 

(Vowles et ai, 2005) provides an interesting perspective on GeoDRM as a spectrum of technologies. 
Figure 2-8 provides an elaborated on version of this DRM spectrum in which we have added the 
knowledge acquired from this chapter to deepen the understanding of GeoDRM. From the figure 
above, we can see that: 

• As business models change according to organizational needs, so do the GeoDRM schemas 
used to disseminate IPR, for example INSPIRE opts for click-through licensing for most of 
the data themes covered by the initiative, while OS already has click-through licensing and 
are opting for Digital licensing and tracking to their assets. 

• The legal framework of GeoDRM is inseparable from the technical framework and together 
they from the essential GeoDRM policy. GeoDRM implementations will use a combination of 
the technical and legal tools to achieve the desired level of IPR management within an 
organization. 
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Figure 2-8 GeoDRM framework components. 



• Trust is an essential component of GeoDRM and is an explicit reflection of the Moral aspects 
of IPR that were discussed earlier this chapter. In the geospatial information sharing a number 
of institutions explicitly admitted to sharing data freely with people they know and Trust, 
while making it difficult for others outside their circle of trust to gain access(Harvey, and 
Tulloch, 2004). Harvey argues that trust from that perspective is important for geospatial data 
sharing and as geospatial information and maps replacing experiential knowledge (e.g. I trust 
that this map is accurate and decision are taking upon that trust) establishing trust in 
geospatial data sharing environments is essential. GeoDRM in that sense by assuring parties 
of the identities of each other's and the preservation of their IPR increases trust in the data- 
sharing environment. 

This research spans on one aspect of the GeoDRM spectrum which is DRM Digital licensing for the 
geospatial domain (GeoDRM Digital Licensing) and particularly for Vector datasets manifested in 
GML. 

2.7. Conclusions 

DRM technology in its broadest sense is concerned with management of all rights on digital assets 
where an asset as discussed pertains to content and services. Although the focus of this research is on 
the technical aspects of GeoDRM Digital licensing, we have demonstrated that GeoDRM legal 
framework are inseparable from the GeoDRM technical framework as this technical/legal setting 
forms the GeoDRM policy of an organization or a certain group of stakeholders. We have argued that 
there exist a clear distinction between IPR laws as statuary rights and licenses as contractual 
agreements between parties and that licensing is the dominant mood of geospatial IPR dissemination. 
Many researchers argue that current copyright laws will need to change to better suit the digital realm, 
since copying is not anymore a sign of the intention to infringe on IPR by users(Mitchell, 2004). In 
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section 2.5 the case of GeoDRM was presented with examples from Geospatial market place vision, 
INSPIRE, OS, and OGC. 

We concluded by a formal definition of GeoDRM and finally by defining the area of interest of this 
research within the GeoDRM spectrum which is GeoDRM digital licensing. Within digital licensing 
this research focus on the rights expression of the licenses and particularly licensing of Vector 
datasets manifested through web feature servers in GML. 

In the next chapter we will introduce the proposed GeoDRM architecture as a solution for GeoDRM 
digital licensing and a GeoDRM Information model to guide the development of an approach to the 
expression of rights on geospatial assets. 
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3. 



GeoDRM Architecture and 
Information Model 



3.1. 



Introduction 



In section 3.2 we first examine the context within which digital licensing occurs by examining the 
DRM infrastructure. We first illustrate the DRM reference architecture and explain its components 
then we examine a modern digital licensing infrastructure that focuses on digital licensing of assets as 
discussed in this work. The findings of these two aspects guide the development of GeoDRM 
architecture (see 3.3). Three usage scenarios of the architecture are then illustrated regarding the 
sequence of interactions on the system. The GeoDRM architecture is a high-level architecture, which 
illustrates the major components of GeoDRM and assists in understanding of the information model 
developed later. 

By combining the knowledge acquired from the scenarios and by examining the essential elements of 
DRM digital licensing we derive the General GeoDRM information model (see 3.4) and elaborate on 
the components of the model in subsequent sections. Later we address the geolicense information 
model (see 3.4.3) which illustrates the essential spatial extension to the digital licensing model based 
on the general requirements derived earlier. This chapter is then concluded in section 3.5. 



In this section, we provide an overview of the GeoDRM reference architecture. To achieve this goal 
we first provide a brief description of the DRM services by examining the DRM reference 
architecture and the digital licensing infrastructure that are common amongst most DRM systems. 
This will enable us to realize the main services that should be enabled by GeoDRM systems. From a 
digital licensing perspective DRM systems and GeoDRM are not fundamentally different we also 
follow an approach on adopting current digital licensing and DRM technology into the geospatial 
domain to build on already established concepts. 

3.2.1. General DRM Architecture 

(Rosenblatt et ai, 2002) introduced a general high-level architecture that is widely adopted in the 
DRM domain as shown in Figure 3-1. This architecture depicts the most relevant components in DRM 
systems. It includes a publisher service that provides the original asset and provides facilities for 
delivery to the client. The licensing server is the administrative hub of the digital licensing server. It 
brokers negotiations between vendors and consumers, grants licenses, the license server generates the 
digital license, and the publisher associates it to the asset being sent to the client. The Recipient or the 
client has a controller service which receives the user's request to exercise certain rights on the 
content(Rosenblatt et ai, 2002). The controller acquires user's identity information and obtains a 
license from the license server. It then retrieves the encryption keys from the license, decrypts the 
content, releases it to the rendering application, and finally executes the license terms. 



3.2. 



The DRM Infrastructure 
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Figure 3-1 DRM Reference architecture (Rosenblatt etal, 2002) 

The above architecture does not provide insight into the process of the management for digital 
licensing. In addition, similar to many DRM implementations it is developed from a content 
background. However, we can deduce three major components from this architecture to guide the 
development of the GeoDRM architecture: 

1. A Provider Server. This issues the assets being licensed. In chapter 2 while defining DRM, we 
concluded on the nature of Assets which could be content or services. This understanding of 
assets shows the shortcomings of the DRM reference architecture which perceives assets only 
as content. 

2. A client component which is an essential component to manage DRM related activities (e.g. 
enforcement of licenses, negotiation with a license server). 

3. A license server. Which is shown in simple form and is based on licensing of discreet unites 
of content. However more recent developments in digital licensing infrastructures have a 
more service oriented approach and stress the importance of interacting with users to define 
licensing terms and conditions for both providers and users (Thompson, and Jena, 2005). 
Such a licensing infrastructure is illustrated in section 3.2.2. 

From the above architecture, we understand the basic skeleton of DRM architectures. We then look 
into licensing infrastructure for the licensing of services and content and address how this licensing 
infrastructure fits the context of our research context of licensing non-discreet assets as addressed in 
section 1.2. 

3.2.2. General DRM licensing Services 

Digital licensing infrastructure as presented here captures the larger picture of services that are 
necessary for DRM systems to function. As shown in Figure 3-2 the digital licensing infrastructure 
enables machines to negotiate and issue licenses to protect assets and to regulate how assets and 
licenses are sold or used. The infrastructure also enables asset holders to track and monitor 
compliance to terms and conditions of use (Thompson et al, 2005): 
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Figure 3-2 Digital Licensing Infrastructure (Thompson etal, 2005) 



Digital license service manages licensing by providing the following specialized services: 

1. DRM packaging Service packages a geospatial dataset file or stream with its license as well 
as encrypt the stream of files if requested at runtime before dispatching the package as a 
Geospatial Object. 

2. Service-Level Agreement service defines an optional section of a license. For certain service 
types (i.e. mission critical or emergency services) some licenses would contain penalties and 
service level parameters. A vendor might agree to pay for underperformance below some 
quantified level of service. Or maybe acknowledge legal liabilities. 

3. Compensation Service defines a compensation scheme and a method of payment. License 
servers would use compensation models such as Pay-me-now perpetual or term limited 
licenses. The consumer purchases a license for use of a given object over a specified time. 
Pay-per-user licenses. The license server generates license keys based on the number of 
standalone applications the service requestor purchases. Pay-per-use or subscription licenses. 
The consumer purchases units of usage of some asset, so a license key is generated every time 
the service is invoked. 

4. The electronic receipt service generates a persistent log entry (e-receipt) for each purchase or 
use of an asset. This e-receipt records which services were used and the form of payment. The 
service can generate e-receipts for geospatial Web services usage, client interactions, calls to 
a geospatial database, or datasets purchased over the Internet. 

5. License Negotiation Service provides offers and counteroffers between vendors and 
consumers until they reach an agreement (translated into a digital license) are reached. 
Negotiation can be manual, semiautomatic, or automatic; the service in the manual case 
would act as a facilitating medium of contact between the two parties involved. 

6. Digital License Service is the administrative hub of the infrastructure through which the 
workflow between the other infrastructure services is managed. Assets being licensed register 
there desired offers within the "electronic licenses" database thus; users can negotiate and 
issue licenses on the desired assets. 

In Figure 3-3, we illustrate the usage of the digital licensing infrastructure through the sequence of 
interactions: 

1. The client request a license offer from the digital license service 

2. The digital license service delegates the request to the negotiation service 

3. The negotiation service determines the identity of the user which is included in the offer 
request, and accordingly issues a callback function to the digital license service instructing it 
to generate a custom offer to the user which include custom SLA and compensation 
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Figure 3-3 Sequence diagram illustrating interactions between the Digital licensing infrastructure services 



4. The callback function from the negotiation service includes parameter values that the digital 
license service uses to construct the offer 

5. The digital license service requests a service level agreement from the SLA service. 

6. The digital license service request the compensation value from the compensation service 
which then credits the user to the account of the author. 

7. The offer is assembled at the digital license service and forwarded to the client 

8. The client may refuse the offer and request another offer which enhances some of the offering 
parameters. Based on this information the negotiation service may issue a callback to the 
digital license service instructing to generate another offer with modified parameters 

9. Once the offer is accepted the digital license service request a receipt from the electronic 
receipt service, which is then forwarded to the client 

10. Every time the client requests to use asset, the client issues a getPermission request to the 
digital rights service to check if the request right is within the bounds of the accepted license. 

11. The digital rights service enforces the right and responds to the client with permission status. 



This digital licensing infrastructure is designed to manage licensing of content and services in a 
variety of settings. We envision that GeoDRM would require such complex licensing capability. In 
this section, we have addressed the DRM reference architecture and analyzed its basic components. 
We then reviewed a service based digital licensing infrastructure and how the services interact to 
fulfill user requests. Earlier this section we established that GeoDRM architecture for digital licensing 
should not be fundamentally different from that of other DRM. Since the entities managed, are digital 
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licenses. While geospatial licenses would be different and would require a certain level of different 
management, we assume that from a high abstraction level the differences between both architectures 
are minimal. 



3.3. 



GeoDRM Architecture 



Figure 3-4 shows a formal UML component diagram of the high level architecture. The GeoDRM 
service is composed of all the services defined in the general DRM reference architecture and digital 
licensing services discussed in 3.2.1 and 3.2.2, which combines the capabilities of modern digital 
licensing infrastructure with client side management of licenses. 
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Figure 3-4 GeoDRM architecture by means of a UML component diagram 



The GeoDRM service can be located in the publisher's environment but it could also be a third party 
trusted license provider service. The client component has the responsibility of managing licensing 
related client side interactions with the GeoDRM service. The GeoDRM service acts as the workflow 
hub of the GeoDRM system and coordinates the interactions between services. A client first searches 
for specific data by accessing the Data Discovery Service. In GeoDRM, we envision the Data 
discovery service to be either one of two or both solutions: 

• An extended CSW, where we envision the metadata defined in the CSW to be extended so 
that users can search for data based on some GeoDRM related keywords, (e.g. if extracting 
feature is permitted). It holds true for service catalogues where service metadata must express 
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relevant GeoDRM metadata criteria (e.g. service requires "pre-licensing", or "release data and 
license later" etc.). 

• A provider would have a product catalogue where they will define a generalized licensing 
policy which provides several licensing schemas mapped to assets so that a negotiation 
service (described below) can negotiate terms with users based on this generalized schema. 
This means that a product catalogue will persist to describe the general licensing rules 
applying to a certain asset. Each license dynamically generated for user who selects a product 
is then a subset of this product catalogue. 

In such architecture, we define two main use categories: a) protect and publish Asset; and b) search 
and acquire an asset. In the case of data publishing, providers perform the following tasks: 

1) Define license terms and pricing schemes. 

2) Using some management tools the vendors create the appropriate REL profile schema to 
support his custom needs 

3) Publish the REL on the GeoDRM system 

4) Create metadata instance using the SDI metadata profile which has an extension to search 
data sets based on right descriptions 

In the case of asset search and acquisition, users (Asset consumers) perform the following tasks: 

1) Access the catalog service on the SDI and search for certain data offered by vendors who can 
provide licenses suitable for the user's needs. 

2) The catalog returns the provider of the needed data. 

3) The user interacts with the GeoDRM system where a data provider is registered to acquire the 
license and data. 

Once users locate the data, they send a request to the GeoDRM gateway which in turn forwards it to 
the GeoDRM service. GeoDRM service interacts with the services that hold the data to generate the 
custom license for the requested asset. The actual sequence of interactions between GeoDRM clients, 
GeoDRM system and data provider may vary from one implementation to the other. The following 
three cases show different interaction flows from data suppliers to users. 

Case 1: License First then Release Data 

1) As shown in Figure 3-5 user searches for the data provider using the OGC catalog service for 
the web (CSW) to locate the data set and provider of interest. 

2) Once the provider is located, user requests the license from the Geogateway. 

3) The Geogateway in turn forwards the request to the GeoDRM service which returns the 
requested license back to the Geogateway 

4) The Geogateway forwards the license to the Client. 

5) Once the license has been received, the controller on the client side may enforce some right 
constraints as prerequisites to requesting data. For example, make online payment. 

6) Finally the client sends a request for feature data based on some spatial criteria, e.g., spatial 
extend. 

This case is most suitable for situations where data acquisition from a certain service requires the 
users to have a valid usage license. In this scenario, possession of a license is a prerequisite to 
acceptance of data requests. 
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Figure 3-5 Case: 1 License First then Release Data 



Case 2: Data First and then License 

1) As shown in Figure 3-6 user searches for the data provider using CSW to locate the data set 
and provider of interest. 

2) Once the provider is located, users request the data set by defining the bounding box of the 
area of interest for example. 

3) Users receive data in encrypted form. Data cannot be used unless the appropriate license is 
acquired. 

4) User requests the license from the Geogateway 

5) The Geogateway in turn forwards the request to the GeoDRM service which returns the 
requested license back to the Geogateway 

6) The Geogateway forwards the license to the Client. 

7) Once the license has been received, the controller on the client side may enforce the license 
terms on the acquired data. 

This case is most suitable for situations for users who already have a data but need to upgrade or 
modify their license terms. For example, a user may possess a dataset for non-commercial use and 
requests a license for commercial use once needed. 
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Figure 3-6 Case 2: Data First and then License 



Case3: Data and License Combined 

1) As shown in Figure 3-7, user searches for the data provider using the CSW to locate the data 
set and provider of interest. 

2) Once the provider is located, users request the data and license together. The user first selects 
the data set by defining a bounding box of the area of interest. The WFS sends the datasets to 
the packaging service which then waits for a license. 

3) The Geogateway forewords a license request using to the GeoDRM service. 

4) The GeoDRM service prepares the license and sends the license to the packaging service. The 
packaging service packages the data with the license and forwards it to the user. 

5) Once the GeoDRM service receives the data set it packages both the license and the data 
together and forwards them to the GeoDRM gateway which in turns forwards it to the client. 

6) The client' s Component may unpack the package and enforce the license terms on the data. 

In this case, the users interact with the GeoDRM gateway which ensures a proper workflow to request 
both data and license from a certain provider according to business model rules set by the provider. 
Also the WFS is assumed to be extended to allow for relevant GeoDRM functionality for example 
each dataset sent must have minimal instructions of where to obtain licenses (e.g. licensing server 
URI is included in the response). 
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Figure 3-7 Case 3: Data and License Combined 



Irrespective of the specific implementation of the three cases above, it can be evident that it is 
important to separate between the license and the data. In earlier DRM systems both data and license 
where hardwired together(Rosenblatt, 2002). This model would not have enabled the first and the 
second cases mentioned above. When licenses are separate from data makes it possible to implement 
the above cases. Hence, the GeoDRM architecture decouples the license from the data asset. It is also 
important to notice that since each user requests a different dataset and negotiates different terms the 
system does not imply a static license schema for the data assets served to users. Each user potentially 
gets a different dataset with different license terms. Having a large number of users each with unique 
license terms is one of the factors for considering GeoDRM technology solutions (see 2.4.2) to 
manage digital licensing of geospatial assets. 



In this section, we have derived the GeoDRM reference architecture along with illustrative usage 
scenarios as expressed in the sequence diagrams. This architecture is based on digital licensing 
infrastructures and hence digital licenses are a core component which forms the basis for the 
information model of GeoDRM. In the next sections, we analyze general DRM digital license 
requirements and establish the GeoDRM information model and then the unified model for GeoDRM 
license (Geolicenses) based on this analysis. 

3.4. GeoDRM Information View 

In sections 3.2 and 3.3, we have introduced the GeoDRM architecture. In the remainder of this 
chapter, we focus on another main aspect of this research. At the heart of DRM system are licenses 
which are containers for the aggregation of rights expressions and acts as the digital equivalent of 
"contractual agreements" or "usage licenses". The information view has two main components that 
we illustrate in this section. The GeoDRM information model (see 3.4.1) that which should contain all 
the elements that form information components in the GeoDRM architecture. In addition, the 
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Geolicense model (see 3.4.3) which represents a generalized view of the geolicense to which we build 
a geospatial rights expression schema in chapter 4. Generally a digital license file that contains(Guth, 
Neumann, and Strembeck, 2003): 

• A reference to the content that is being licensed 

• The conditions of use on that content 

• Miscellaneous additional information (Copyright or other legal statements) 

• Decryption keys to decrypt an encrypted content package and make it available to the user 



JID = msmrth 
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Figure 3-8 DRM Rights Object (Guth etal, 2003) 

An active instance of a DRM license is referred to as the "Rights Object" (Figure 3-8). From the 
GeoDRM architecture, we can safely assert that the information model of GeoDRM and that of DRM 
is not fundamentally different for two major reasons. First, the GeoDRM licenses are serving the 
same general purposes which are projecting contractual agreements between parties over assets. The 
fundamental difference is in the nature of those assets which could be geospatial web services or 
geospatial datasets. Second reason is that the GeoDRM architecture uses similar service management 
infrastructure. 
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Figure 3-9 Taxonomy of current Rights Expression Languages (RELs) 



In chapter 1, we have briefly enumerated the rights expression languages available which are mainly 
ODRL, XrML, MPEG-REL21, and ISO-REL 21000-5. The latter three languages are very similar, 
since MPEG-REL and ISO REL are both based on XrML. The Taxonomy of RELs is illustrated in 
Figure 3-9. 
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Digital licenses are expressed by means of Rights Expression Languages (RELs) which aim to 
provide a vocabulary and semantics for the expression of terms and conditions over (digital) assets. 
RELs aim to enable a machine-based processing of digital contracts (Guth et al, 2003). Others define 
a REL as a type of policy specification language where the focus of the language is on expressing and 
transferring rights from one party to another in an interoperable format (Lamacchia, 2002). 
The Concept was invented when Digital Property Rights Language (DPRL), a LISP 1 based language, 
was developed by Mark Stefik of Xerox's Palo Alto Research Centre. Stefik created DPRL as a 
machine -readable language that could be used to define access rules and procedures, for use with the 
trusted PC. Stefik made DPRL 2.0 XML-based, because XML is extensible and interoperable with 
other emerging standards. From DPRL emerged ODRL and XrML. Based on XrML ISO-REL and 
MPEG-REL have been developed. (Chong, 2005) identifies four general components of a REL, 
Figure 3-10: 

• Subject, which is an actor who performs some operations; 

• Object, which is the content acted upon by a subject; 

• Right, which is what a subject can do to an object; and 

• Constraint, which describes limitations on the rights granted. 
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Figure 3-10 Main elements of a rights expression 

RELs depend on the notion of licenses as unites of aggregation of rights. Digital licenses and 
licensing infrastructures have been previously examined. The elements in figure 3-10 have different 
names in different RELs. For example, The Object in Called an Asset in ODRL and an Object in 
XrML. the Subject is called a Principal in XrML and a Party in ODRL. ODRL "constraints" are 
mapped to "conditions" in XrML. 

Beyond the above four elements we have noticed within RELs specifications the universal existence 
of a security model. This security model consists of trust information and asset protection information 
ranging from encryption keys to watermarking and fingerprinting techniques (explained later next 
section). Also unique identification information is an essential part of RELs so that we can uniquely 
identify assets, license objects, and parties. 

By considering the general elements of RELs mentioned above and the four elements in Figure 3-10 
we can assert a general digital license information model independent of RELs. In the next section 



1 Acronym for list processor, a high-level programming language especially popular for artificial intelligence 
applications. LISP was developed in the early 1960s by John McCarthy at MIT. 
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3.4.1, we illustrate the general GeoDRM License information model which is independent of any 
specific REL with illustration of its individual elements. 



3.4.1. 



GeoDRM License information Model 



A license data model is specified by means of a Right Expression Language (RELs) in which case the 
structure of the language schema and its semantics determine the exact data model of the language. 
From a conceptual perspective, we provide the GeoDRM license information model independent of a 
REL. In implementation However, DRM licenses cannot be modeled in isolation from a rights 
expression language and since it carries usage rights (and keys to unlock the protected content in case 
of encrypted packages), the license also needs to be protected from tampering with its structure -giving 
rise to the security model of the license. In this section, we have projected the information model 
elements for DRM into the GeoDRM to enable modeling of the general GeoDRM license information 
model while extending it to show where spatial properties are needed from a high perspective. Figure 
3-11 illustrates the general GeoDRM license information model. The rest of the sections are as well 
used to define each of the elements of the GeoDRM information model which are listed below: 
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Figure 3-11 The GeoDRM information model 

1. Rights Information: A definition of types and meanings of permissions that may be granted in 

a license, and spatial and non-spatial permissions and how to express the spatial permissions. 

2. Rights Constraints: A definition of the types and meanings of spatial and non constraints that 
may apply to each permission, principal or resource 

3. Unique Identification: unique identifiers are required for the following reasons: 
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a. Provide unique identity to the geospatial assets holders and licensees in an open 
distributed environment like the Web. 

b. Enable licenses to refer to assets that are being managed in GeoDRM. 

4. Geospatial Rights Metadata: general information to enable the search and discovery of assets 
in a web environment based on a certain GeoDRM criteria (e.g. rights). 

5. Trust Information: signature and trust information for authentication of identity and to verify 
that the license has not been modified in any significant manner. Also trust in the social sense, 
which can be asserted when parties in a transaction are well defined. 

6. Asset Protection: these are mechanisms to embed information with the assets so they can be 
recognized and any misuse can be detected and attributed to the infringing parties. 

3.4.1.1. Rights Information 

This is the major focus of this research and a spatial rights representation approach is presented in 
chapter 4. The Rights in the broadest sense as identified by DRM are actions (or activity) or class of 
actions that a subject may perform on or using the associated asset(Contentguard, 2001; Iannella, 
2002; Park et al., 2004). Recall that in the beginning of chapter 2 we highlighted the similarity 
between access control and DRM. Rights therefore, enable users to access assets in a particular mode, 
such as read or write(Park et al, 2004). (Rosenblatt et al, 2002) identifies, render rights, transport 
rights, and derivative rights as the three types of rights. According to Rosenblatt, the three mentioned 
categories of rights are assumed comprehensive, but the rights within the categories (i.e. play, extract, 
etc..) vary according to the type of content and its applications. 

In addition to the above three types of rights, issuance rights (the right to issue grants of other rights) 
and delegation rights (the right to delegate a grant to another party) are examples of essential rights 
over rights. We collectively call these types of rights Administrative Rights (Chong, 2005) which add 
to the core types of rights addressed above. These rights categories are a general functional 
categorization of rights that fits any digital rights domain such as GeoDRM. 

1. Render Rights: relates to representing the content on some output medium (i.e. Play, view, 
print, etc..) 

2. Transport Rights: (i.e. Copy, Move, Loan, etc..) are the rights to move or copy content 
from one place to the other the differences for example among the copy, move and loan have 
to do with which users have access to the content at any given time. In the first instance 
(copy) user 1 give copy of content to user 2, both have access to the content simultaneously. 
While (move) means user 1 gives up access once content is moved to user 2. (Loan) means 
user 1 does not have access to content temporarily after lending the rights to the content to 
user 1 until user 2 gives the rights back to the content server. 

3. Derivative work Rights: (i.e. Extract, Edit, Embed, etc..) have to do with manipulation of 
the content to create derivative work for example (extract) has to do with the right to use 
pieces of content on there own and extracting it out of its context. (Edit) are the right to make 
changes to the content. (Embed) is the right to embed the content into another product. 

4. Administrative Rights: rights over rights (e.g. the right to delegate a certain set of rights to 
others). 
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A special type of rights for the Geospatial domain are Geospatial rights which are shown in the 
diagram as a specialization. Example of which is an Extract feature right which is of type derivative 
work rights. In section 5 we implement various spatial rights. 

3.4.1.2. Rights Constraints Information 

Constraints on rights are attributes that are attached to each of the fundamental rights mentioned 
above. Attributes include considerations, extents, types of users (Rosenblatt et al, 2002). Spatial 
constraints are also needed. Since the constraints are on the use of geospatial assets. 

1. Considerations: is whatever a user has to give in exchange for a certain right. An obvious 
consideration could be money, or it might be a certain form of agreements between the 
publisher and the user. For example, a publisher might allow someone to use his content to 
produce work in return of a copyright notice in the produced work 

2. Extents: relates to how long, how many times, or in what places the rights apply. 

3. Types of users: it allows for specifying sets or rights and right attributes to particular user or 
category of users. For example, you can have educational institutions as a particular category 
of users. 

3.4.1.3. Unique Identification Information 

Unique identification of licensed content is an integral part of any DRM license. Digital Object 
Identifier (DOI) is a standard for online content identification and linking based on URI and URN 
governed by the International DOI Foundation. Digital content using the DOI system is given a unique 
alphanumeric character string that is used as an identifier. The identifier is comprised of a prefix and a 
suffix, separated by a forward slash. The prefix is assigned by the registering agency and identifies the 
specific organization, and the registrant to identify the unique content provides the suffix. The DOI 
also comes with metadata that describes the content. The DOI of an object is permanent so that the 
content can always be located if the URL of it changes (the user will be redirected to the new 
location). The technology was developed to protect the copyright of material published on the 
Internet, to compensate content creators for their work, and to keep track of content. 

Using the DOI to uniquely identify any digital asset be it data or service means assigning a DOI to the 
asset. Regular URLs as a mean of identifying digital content is not successful because they point to 
specific location of an asset or files. If the location of the asset changes the URLs become invalid. 
DOI point to a master table called the DOI directory where each DOI record is assigned a URL that 
leads to the asset of the URL. URL changes are always synchronized with the DOI directory. 

For example 11.2067/plot.trll.0019 is formed of a prefix and a suffix after the slash. The prefix 
(11.2067) points to a publisher or content author while the suffix (plot.trll.0019) points to a specific 
content or service. Many publishers have already adopted DOIs by putting a suffix to the ISBN or 
ISSN of their publications. DOI so far is proving to be successful in the publishing industry. In the 
realm of the DRM, DOIs can be used to uniquely identify the license objects. Similar techniques can 
be used to uniquely identify assets in GeoDRM licenses where each geospatial provider would have 
his own unique identifier that identifies his own assets. 
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3.4.1.4. Rights Metadata Information 

When publishing assets in an open and distributed network like the Web, users need to be able to 
search and discover assets based on different generalized information. For example users can search 
music based on genre, date of creation, etc. Although this specific element is not mentioned in the 
DRM literature, we believe it is an important aspect that is specific to geospatial data. In the 
geospatial realm, users can search data metadata catalogues based date of creation, keywords, etc. The 
role of metadata is to provide information about collection of assets to enable search and discovery. 
OGC has defined the Catalogue Service for the Web (CSW) to enable clients search and discover data 
based on well-defined metadata elements. These elements are defined in the ISO 19115. We 
recommend an extension to the ISO 19115 metadata standards and its implementation in the CSW to 
support searching data based on some geospatial rights metadata. Although it is outside the scope of 
our research, we believe a GeoDRM CSW profile to be an important aspect that has yet to be 
considered by the OGC GeoDRM working group. In general, we recommend the following categories 
as guidelines to for the rights Metadata: 

• Licensee metadata: consists of general information about types of users who can have licenses 
and access rights to the asset (e.g. academic institutions, commercial users). 

• Licensor metadata consists: of general information on the authority, that controls the data. 
This type of metadata is similar to subsections of the ISO 191 15 metadata standards. 

• Rights metadata: consists of general information about the types of rights and constraints that 
are generally applied on collection of assets. 

3.4.1.5. Trust Information 

Trust has both Technical and social meaning. From a technical perspective, a trusted system is a 
system that can hold digital works and which can be trusted to honor the rights, conditions, and fees 
specified for a work. Trusted systems can take different forms, such as "trusted players" that play 
digital works, or "trusted readers" for reading digital works or "trusted servers" that may provide 
access to digital works on a network. Different implementations of trusted systems have different 
requirements for security and different approaches. In the most secure approaches, all of the hardware 
and software on the platform is certified to honor digital rights. Other approaches focus on the use of 
so-called secure envelopes or containers, emphasizing transmission and storage of information. All 
such approaches have some elements that are assumed trusted and can be circumscribed by 
boundaries of trust. These boundaries may be the boundaries of program code assumed not to be 
altered, data files assumed not to be accessible, language interpreters (such as Java) assumed to follow 
certain rules, or physical hardware assumed not to be compromised. The security of a trusted system 
depends in large measure on its vulnerability across these boundaries (Vingralek, Maheshwari, and 
Shapiro, 2001). 

Public Key Infrastructures are set of servers, software, protocols and application programs used to 
manage the Private Key's and Public Key's of a group of users (Keys a cryptography mechanisms used 
to encrypt or to digital sign digital assets). Users are generally able to create and update their own key 
pairs, and a Certificate Authority is used to sign new Public Key's. Some mechanism is made 
available by which users may conveniently and reliably retrieve and use their own Private Key's and 
other users' Public Key's (Sandhu et al, 1994).. For example in recent years, research in 
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authorizations has been pursued under the name of trust management. Both traditional access controls 
and trust management deal with the protection of digital assets within the trusted environment of an 
asset provider (Park et al., 2004). None of these systems deals with protection of assets on the client 
machine outside the trusted environment of the provider. (Schneck, 1999) introduced a new 
perspective on access control problems considering requirement for persistent access control, in the 
sense that protection of any digital asset occurs wherever this asset exits (e.g. on a server or when 
content is moved to a client environment). 

From a social perspective GeoDRM have significant impact on Trust between parties participating in 
geospatial information sharing be this for intergovernmental or private sector to government as 
asserted from (Harvey, 2003; Harvey et ah, 2004) and illustrated in the GeoDRM definition in chapter 
2. This also applies to commercial geospatial information transactions. The Effect of trust on 
GeoDRM enabled SDI could be on many fronts. Examples of which are: 

• Accessing a geospatial service after signing a digital license specifying a "level of service 
agreement" and "terms of use" has an effect on the trust among the parties involved and 
on the level of service (i.e. do I trust this service enough to build an emergency 
application on it?) 

• A government entity "G" licenses a valuable dataset with an IPR license giving a 
restricted set of uses to user X for non-commercial use. Such transaction and use of 
digital licenses vests more trust into participating parties since all participant and rule are 
well defined. 

A minimum level of information is required in any GeoDRM license to insure parties involved in an 
agreement can assert trust in each others regarding these transactions. We also envision that trust 
would be a context sensitive elements. That means for example in certain situations the quality of the 
dataset could be the major element of trust. In another cases the party from which the data originates 
is the element of trust. 

3.4.1.6. Asset Protection Information 

Digital content can be encrypted to scramble the content packages, which then need to be decrypted 
by private keys embedded in the license to the content. The content can't be decrypted and used 
unless a valid license with the corresponding keys is made available (Rosenblatt et al, 2002). 

Digital watermarking is an adaptation of the commonly used and well-known paper watermarks to the 
digital world. Watermarking makes it possible to embed some essential metadata fragments within the 
content instead of having metadata alongside the content (Rosenblatt et al, 2002). It describes 
methods and technologies that allow hiding of information, for example a number or text, in digital 
media, such as images, video, and audio. The embedding takes place by manipulating the content of 
the digital data. That means the information is not embedded in the frame around the data. The hiding 
process has to be such that the modifications of the media are imperceptible. 

Research in geospatial content water marking is still in its infancy. However, in digital imagery it is a 
more mature area than vector geographical information, even with multiple commercial vendors 
offering watermarking protection. 2D vector and point datasets have received less attention from the 
research community(Lopez, 2002). 
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3.5. Geolicense Specific Requirements 

In the previous section, we identified the main elements of the GeoDRM information model. The goal 
of this section is to identify the requirement two main aspects that are specific to geospatial 
information as stated in section 1.2. The first aspect relates the ability to resolve the problem of non- 
discreet assets, while the second relates to combining multiple datasets. 

In the first aspect of the problem, we addressed the fact that in non-spatial DRM licensing is for assets 
where the assets are discreet units such as a book, or multimedia file for example. On the Geospatial 
domain, the asset is a little bit more complex. A district of a city when licensed is originally a part of a 
bigger whole, which is the dataset of the whole city (Figure 3-12). Further more one can have a 
license for patches of the district and not for an entire district. Making the geolicense more of a 
mechanism to cut through a continuum which the entire larger dataset. In this research, we tackle this 
problem. Basically, licenses act as a clip operator on the larger dataset where the clip is the license 
extents. 




Figure 3-12 Geolicense cutting through a continuum of the larger dataset A 

We previously mentioned that the nature of assets is a fundamental difference regarding GeoDRM. In 
this research, we are concerned with developing an approach to the expression of rights on GML data 
assets. This requires us to define what an Asset in GML with regard to the rights expression. Hence, 
we can understand the requirements that need to be satisfied by a certain REL. 

Figure 3-12 illustrates the GML data Asset. In any rights expression we specify rights over assets. 
From a GML perspective an Asset can be defined in three distinct methods to enable flexibility of 
defining the extents of the license 

a) As a GML bounding shape the bounds the dataset. 

b) As a GML feature and 

c) As a gmlFeature collection. 

These three methods can be combined together so that assets can be defined such as for example "the 
extent of this license is R and it pertains to this particular feature Types Y in dataset a that allows you 
certain rights R. If you get a feature type Y outside the valid extents of the license then the rights R 
don't apply". In that, sense the license extents acts as a clip mechanism cutting through the geospatial 
dataset continuum. This satisfies the core aspect .stated in section 1.2. Hence, geospatial licenses must 
be able to express geospatial boundaries and geospatial properties to cut to the spatial continuum of 
the dataset. 
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Figure 3-13 GML Assets in GeoDRM 



Also in the GeoDRM architecture, scenarios (see 3.3). A user would acquire a license and request 
data from a WFS. We envision that the WFS would be able to authorize the data release after 
authenticating the license and extracting the correct data request from the license (e.g. bounding box). 
Hence, the license needs to specify the extents of the asset covered unambiguously. In addition, non- 
spatial DRM, license references assets by using unique identifiers as mentioned in section 3.4.1.3. It 
is also possible to identify geospatial features, encoded in the GML using unique identifiers (OGC 
2005-GML), in which case the gml:id property of features and feature collections can be the database 
unique identifier (e.g. TO ID in case of ordnance survey master map). 




Figure 3-14 different ways to handle heterogeneous licenses 
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The second aspect discussed in section 1.2 relates to the ability to merge geospatial data while 
maintaining the semantic consistency of the licenses. It is important to note here that the second 
aspect although important, its solution is considered to be outside the scope of this research. In 
chapter 5 (conclusions and recommendations) we recommend an approach that requires further 
research to solve this specific problem. Integrating geospatial content from multiple data sources may 
require licenses to be modified. Figure 3-14a, shows the simplest case occurs when a client receives 
data with well-defined license. In 3-14b, a client may receive three different data sets (layers A, B, 
and C) and maintain the license of each individual set. This however, may lead to some conflicting 
rights when users attempt to merge the data. In the third case 3- 14c, the GeoDRM system of the client 
may be able to generate a semantically consistent license that spans the three data sets. 

From the above discussion, and the work done on this chapter following is a list of requirements for 
declaration geolicenses on Geospatial Features. It is important to note that these requirements focus 
mainly on Assets in the GML sense. Although other requirements for other data types are outside the 
scope of the proof of concept implementation, we believe that many of these requirements are also 
applicable to Maps and Coverages: 

1. Rights Granularity: According to the definition of a GML asset specified in this section, the 
granularity of the expression of rights spans features, features collections, and asset 
boundaries. This enables complex specification of expressions as previously illustrated. In 
addition, same reasons suggest that granularity might be refined to individual properties of 
each feature. However, and in the long term, such model may burden GeoDRM systems with 
the task of tracking the use of each property. We believe this to be a model that cannot scale. 
We therefore believe that REL should only enable granularity on feature instances and their 
collections thereof along with the boundaries. This requirement will be considered in Chapter 
5. 

2. Types of Permissions: right permissions should consider whether the act will affect the 
geospatial content or not. For example, printing does not alter the data, while coordinate 
transformation will. This requirement will be considered in Chapter 5. 

3. Administration rights: REL should enable update or change of rights permissions. To be 
able to regrant rights to others for example. This requirement will be considered in chapter 5. 

4. Composite License: The REL should support building license from multiple heterogeneous 
licenses of data coming from different providers. The process of automatic conflict resolution 
and construction of homogeneous license is outside the scope of this research. However 
having structured licensing framework is a step towards the realization of this aspect 

5. Spatial extent of licenses: the REL should enable rights definition based on the 
geometricboundaries of datasets. This requirement will be considered in chapter 5. 

3.6. Geolicense Information Model 

Earlier this chapter we have provided the general GeoDRM license information model independent of 
the RELs. This information model forms the basic structure of the information entities that need to be 
researched to enable a full-fledged GeoDRM system. We abstract the general geolicense information 
model using a REL in this section to be able to perform the proof of concept. We have addressed that 
RELs provide the essential semantics for expressing digital licenses. Attempts to model licenses 
without reference to a specific REL schema in implementation phase would result in a considerable 
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redundancy in the development effort. Hence, to model the Geolicense for which we provide the 
implementation in chapter 4 have adopted the semantics of Open Digital Rights Language (ODRL). 
ODRL in general is discussed in more details in chapter 4. 

Figure 3-15 illustrates the Geolicense model implemented in the next chapter that has the following 
classes: 




Spatial Permission 



1 1 I 

Figure 3-15 the geolisence model 

• The license class (rights object container): is the major entity of the Geolicense and at the 
very least must be composed of one party, asset, and an agreement classes. It acts as the 
container of the license entity and aggregates the basic license elements. Parties and assets 
can be defines globally and have the license class as their container. 

• The Agreement class: the agreement is the part containing the terms and conditions of the 
license. In the Geolicense, if parties and assets are not defined globally they must then be 
defined as part of an agreement. This also contains permissions. In all cases permissions must 
be contained within agreements as agreements act as units of aggregation of permissions. 

• The Asset: is the object being licensed to which we have adopted a certain definition in this 
thesis as expressed in section 2.3. Assets in the Geolicense have geometric properties such as 
spatial boundaries to enable expression of geospatial resources. 

• Party: is an entity that has a role of a subject who has any role relating to the asset. (Owner, 
licensee, licensor, etc). 
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• Rights holder: The Rights Holder is a recognized Party (who receive compensation for the use 
of the asset) and has facility to specify any set of entitlements that they are due for the use of 
their Asset. 

• Permission: is an act to which a party is entitled to over an asset 

• Spatial Permission is a specialization of Permissions which should have Geometric and other 
properties to specify permissions over geospatial assets. 

• Constraint is a restriction which can be applied to both permissions and agreements (e.g. 
perform a certain act once. Or in a certain quality) 

• Spatial constraints are specializations of constraints that have geometric and other properties 
to be able to express constraints on spatial permissions. 

• The Requirements are sets of preconditions that need to be fulfilled before permission is due 
to a party. 

• The conditions are conditional events that if true render the permissions invalid. 

3.7. Conclusions 

In this chapter, we have presented the GeoDRM architecture in the form of loosely coupled services 
each of which performs a key task in management of digital licenses. Later in the chapter we 
presented the GeoDRM license information model and elaborated on the individual elements these 
elements constitute the essential elements for a full-fledged GeoDRM implementation. This 
information model is independent of any REL and represents a generalized view. Each of the elements 
within the information model need further study beyond this research to define its specific elements 
and implementation details. We used the geolicense information model in conjunction with ODRL to 
derive a geolicense model based on ODRL was presented illustrating a view of the geolicense for the 
digital licensing of GML datasets. This model then guides the development of the extension of ODRL 
represented in chapter 5. 

In the next chapter, we address the implementation of the geolicense model by extending the ODRL 
with spatial data types and necessary extensions 
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4. GeoREL Development and Proof of 
Concept 

4.1. Introduction 

In this chapter we introduce the Geospatial Rights Expression Language schema (GeoREL) which 
follows on the model developed earlier (see 3.6). and is developed to accommodate the requirements 
of the licensing scenario developed in this chapter for licensing vector datasets. In section 4.2 we 
provide an introduction to the Open Digital Rights Language (ODRL 2002) which is an open source 
rights expression language. Being open source and lightweight makes it ideal for the proof of concept 
we intend to provide in subsequent sections. 

In section 4.3 we present the approach to the extension of ODRL to build the GeoREL, this extension 
uses GML to build spatial data types to accommodate spatial requirements of rights expression. The 
use of GML schema in developing the GeoREL schema provided strong spatial extension to the 
ODRL and it enabled us to define spatial boundaries, for the Geolicense as well as spatial permissions 
and the ability to express rights on the feature and feature collection level. This means that a high 
degree of granularity of the rights have been achieved within the Geolicense. Section 4.4 illustrates 
three scenarios with three different Geolicenses based on "Ordnance Survey's Print/Copy Shop 
License". These three scenarios demonstrate the ability to form syntactically correct Geolicenses 
based on the developed GeoREL schema. 

4.2. Open Digital Rights Language (ODRL) 

ODRL 1.1 specification (ODRL 2002) focuses on the semantics of expressing terms and conditions 
on licenses of digital assets. ODRL can be used within trusted or non-trusted systems for both digital 
and physical assets. However, ODRL does not determine the capabilities nor requirements of these 
environments (e.g. for content protection, digital/physical delivery, and payment negotiation) that 
utilizes its language. It is solely focused on the expression of rights in digital licenses. 

ODRL standard provides two schemas (see Figure 4-1): 

■ the right expression constructs in the expression language schema and 

■ definitions of instance elements in the data dictionary 

The expression language schema (ODRL-EX package) provides the basic structure of the language. 
While the data dictionary (ODRL-DD package) provides additional elements essential for building, 
working XML instances such as new permissions, or constraints. ODRL is also an extensible standard 
it can be extended with new additional data dictionaries to add more expressive vocabulary to the 
language. Hence any new extension of ODRL involves establishing a new domain specific data 
dictionary. 
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Figure 4-1 The Standard ODRL 1.1 Package Diagram 



To build new elements within a new data dictionary and still preserve the language structure the 
expression language schema defines elements that are utilized as placeholders for additional data 
dictionary elements, These elements are: 

• permissionElement (permissionType) 

• requirementElement (requirementType) 

• constraintElement (constraintType) 

• conditionElement (conditionType) 

• contextElement (contextType) 

• rightsholderElement (rightsHolderType) 



The elements above are defined as "abstract" ensuring that they cannot appear in an instance of an 
ODRL XML expressions and by default are of "any Type" data type to allow maximum extensibility 
(e.g. by building more complex datatypes). The Data Dictionary schema utilizes the 
"substitutionGroup" mechanism from XML Schema to ensure that only the appropriate elements can 
be used in the correct position in the ODRL Expression Language. The ODRL specification provides 
detailed explanation and data model for each of the elements below: 



For example, the ODRL Expression Language schema defines the abstract element: 

<xsd: element name= "permissionElement" abstract="true"/> 



To extend the language the specification mandates establishing a new application specific DD 
schema. Using the above expression from the Expression Language Schema a new permission 
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element to give the "Display" right can be defined in the ODRL Standard Data Dictionary schema, 
such as: 

<xsd: element name =" display" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

The permission "display" is of the type "o-ex:permissionType", other complex (e.g. Spatial) data 
types can then be developed and integrated within the language. The specification provides the 
standard schema of the rights expression under the namespace "o-ex" and the standard data dictionary 
in the name space "o-dd". We have built an additional spatial data dictionary to be able to express the 
GeoLicense in the namespace "georel-dd". 



<o-ex:rights> 

<o-ex:context>. 

<o-ex:uid> ... </o-ex:uid> 
</o-excontext> 
<o-ex:agreement> 

<o-ex:context> ... </o-ex:context> 
<o-ex:asset> ... </o-ex:asset> 
<o-ex:permission> 

<o-ex:permission-type> 

<o-ex:requirement> ... </e-ex:requirement> 
<o-ex:constraint> ... </o-ex:constraint> 
</o-ex:permission-type> 
<o-ex:condition> ... </o-ex:condition> 
</o-ex:permission> 
<o-ex:party> 

<o-ex:context> ... </o-ex:context> 
<o-ex:rightsholder> ... </o-ex:rightsholder> 
</o-ex:party> 
</o-ex:agreement> 
</o-ex:rights> 



Above is the simplified XML instance of ODRL. The "<o-ex:rights>" In ODRL vocabulary refers to 
the root element of the whole rights object (a license instance); however, rights as defined earlier in 
this work are known in ODRL as "Permissions". 

4.3. The ODRL Spatial Schema Extension (GeoREL) 

We have identified the core components of ODRL in 4.2 and we have established that all RELs share 
the same semantics while the vocabulary for expressing the semantics differs (see 3.4). The same 
approach used with ODRL can then be used with other RELs to achieve similar goals by using the 
REL semantics and projecting it to the developed GeoREL model to make it relevant for a particular 
REL. 

ODRL can't be used directly for the Geolicense as by default it does not provide spatial data types. It 
also does not provide the ability to describe on geospatial assets as described in this thesis (see 3.5) or 
any spatial elements in general like spatial permissions. These are not shortcomings of ODRL since it 
provides generic vocabulary for rights expression. Rather these are issues left to be resolved in 
domain specific data dictionaries. In this section, we explain the extension methodology of the ODRL 
language to build a geospatial profile of ODRL which would enable expression of the Geolicense 
3.4.3. The detailed data dictionary schema developed at this research are attached in Appendix A. 
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In Figure 4-2 we illustrate the high level data model of the GeoREL schema by means of a UML 
package diagram. The two packages ODRL-EX and ODRL-DD as previously illustrated are the core 
Schemas of the ODRL. To enable geospatial rights expression we Extended ODRL with an additional 
data dictionary which is the package GeoREL-DD. We then used imported vocabulary from GML 
schema is enable building spatial types and GML types within GeoREL-DD. The GML application 
schema package is a representation of a Generic application schema. 
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Figure 4-2 GeoREL Package Diagram, the composition of dependencies of the GeoREL schema 
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In GML the application schema (OGC 2005-GML) is a domain specific Schema based on GML. For 
the GeoREL-DD to be ready for expressing rights on a certain dataset the application schema of this 
dataset needs to be imported within the GeoREL-DD, hence it become possible with the mechanism 
developed within the GeoREL-DD to specify rights expressions on the feature or feature type level of 
this particular application schema. 
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Figure 4-3 the conceptual model of the developed GeoREL data dictionary schema structure 



In Figure 4-3, the UML class diagram of the GeoREL data dictionary schema that is used to illustrate 
the Scenarios in section 4.4 is presented. The class "contextElement" is generic in ODRL and exists 
as a component for all other major elements in the language it can be used to express any additional 
information about the element. The diagram illustrates that "Asset", "Permissions", "Constraints" and 
"Requirements" (yellow classes) all have contextElements. Thus, any elements available for the 
context are available for all the other classes. In the contextElement, we define two spatial elements 
(blue classes), which we elaborate on later. One is used to define Spatial Boundaries, and the other is 
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used to define GML Features, Feature collections and Feature Types (OGC GML 2005). We also 
define two classes of spatial permissions (purple classes). In addition, non-spatial permission (regrant) 
is defined to allow for transfer of rights to other parties. 

In the rest of this section, key GeoREL elements are explained to illustrate the derivation of spatial 
elements. While illustrative examples of the Geolicense instances are used to further illustrate the 
usage of the GeoREL schema in constructing geolicenses for licensing scenarios to validate the 
approach against the scenarios in section 4.4 

Defining Spatial Boundaries 

To be able to define spatial boundaries for the extents of the Geolicense, the ODRL "context" element 
was utilized. Most entities in the ODRL model can support a specific context. A Context, which is 
relative to the entity, can describe further information about that entity in defining an Asset the 
context element is utilized to express the spatial boundary. Extending from "contextType" a new 
spatial type was built adding "gml: envelope" datatype, gmhevelope defines an extent using a pair of 
positions defining opposite corners, the first is "lower corner" the second one the upper corner". The 
spatial "context Type" was then used to 
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Figure 4-4 the boundary context element 

construct a "georel-dd:Boundary" context element within ODRL. (Figure 4-4) illustrates the structure 
of the GeoDRM boundary context data type. This can now describe bounding boxes on datasets 
within any entity of the rights expression. With this extension the "gml: envelope" describing the 
boundaries of certain datasets can be projected in the rights expression. Also Envelopes with Time 
period can be utilized to describe temporal boundaries (in case of coverages). The fact that Boundary 
is a GeoREL context element means it can appear in any entity within the other elements that have 
context as illustrated before in rights expression to enable complex specification of spatial 
boundaries. 
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Defining Feature and FeatureType Elements 

Another challenge was to build fine-grained right expressions, which requires the ability to specify 
expressions on specific GML features and feature collections as well as feature Types. 
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Figure 4-5 appschema element to declare feature level context elements 



Figure 4-4 illustrates a new element "georel-dd:gmlappSchema". The approach followed depends on 
the XML schema type checking capabilities and the use of any GML application schema (a sample 
application schema is illustrated in section 4.4). Each vendor releasing his own datasets as GML 
would have his own GML application schema pertaining to his data model. We need to import the 
vendor application schema in our developed GeoREL Data dictionary to enable the use of the 
developed functionality to specify rights on features and feature collections. 



First step is building a spatial datatype of type gmhAbstractFeatureType, this spatial type is then used 
as part of a new GeoREL schema type with extension of an ODRL standard (contextType) which was 
then used to construct the spatial context element "georel-dd:gmlappSchema". Second, since the 
gmhAbstractFeatureType is the basic GML feature model which means that for GML instance of this 
application schema where features or feature collections are always of type gml:_Feature and 
gml:_FeatureCollection we can specify Feature types or individual feature instances within the 
"georel-dd:gmlappSchema" ODRL element. This solution is versatile, since it allows each vendor to 
import his own GML application schema to the GeoREL data dictionary; hence the extension 
supplied can describe features in rights objects within the vendor's specific domain. 

Defining spatial permissions 

Another spatial extension is "georel-dd:CoordinateOperation" permission (Figure 4-5) which uses the 
gmkldentifierType to identify specific GML coordinate operations such as coordinate 
transformation using the GML vocabulary and semantics. Figure 4-6 below illustrates the 
permission structure. Other permissions like "ExtractFeature" uses spatial components that 
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have been developed earlier like feature and feature level GML application schema elements 
to specify which features are allowed for extraction. Section 5.4 provides examples on the 
uses of these permissions. 
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Figure 4-6 the Coordinate operation spatial permission 
Defining non-spatial permissions 

Other permissions, requirements, and constraints were needed for the proof of concept scenarios 
which have no spatial properties. An example of these is the permissions is "georel-ddregrant" 
(Figure 4-7) which pertains to re-granting certain sets of permissions from a licensee down stream to 
sub-licensees the elements in the namespace "o-ex" are the standard ODRL child elements inherited 
by all spatial and non-spatial permissions. For more details on the schema structure refer to the 
schema and the schema documentation in Appendix A 
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Figure 4-7 the regrant non-spatial permission 
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4.4. Proof of concept 

In this proof of concept, we have built licenses based on the developed Geospatial data dictionary 
"georel-dd". The licenses revolve around a scenario adopted from Ordnance Survey Print/copy Shop 
License (OS 2006 BL). Also we have adopted a GML dataset (Matheus, 2005) that is assumed to 
belong to OS for use within the scenarios. 

Due to the lack of GeoDRM technology stack to establish a test-bed the use of the software Altova 
XMLSpy IDE provided validation for both the developed schema as well as the licenses discussed 
later in this section. To provide insights on the rights expression using the GeoREL we have the 
City Model GML dataset (Figure 4-8). 
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Figure 4-8 CityModel GML Visualization 



The GML city model is a GML instance. As previously mentioned each GML instance has a 
supporting application schema. The application schema of the City Model is illustrated below in 
Figure 4-9. The application schema defines four types of features, Building, Intersection and Street. 
Each of these features is substitutable for gml:_Feature. And the fourth type is CityModel which is 
substitutable for gml:_FeatureCollection. The CityModel schema and the CityModel GML schema 
instance (the dataset) are attached in (Appendixes E, F). As previously illustrated the Developed 
GeoREL-DD is ready to express Geolicenses one we import the application schema of the dataset on 
which the Geolicense is specifying agreements. For the next illustrative examples we use the 
CityModel application schema which is then imported into the GeoREL-DD as illustrated in (Figure 
4-2) to build GeoLicenses for the CityModel dataset used on the three examples illustrated below. 
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Figure 4-9 City Model Application Schema 



4.4.1. OS Print-shop License 

In this scenario, we implement the "Ordnance Survey printer/copy shop license" (OS 2006 BL). In 
this license, OS gives authorization to certified print shops to provide printing services on ordnance 
survey datasets for varying customer needs. Each shop willing to take part in this program signs a 
license agreement with OS granting the print-shop the right to print map sheets on certain paper sizes 
and for each print ordnance survey receives a designated amount of money in royalties. Other terms 
such as printing watermarks and identifying purpose of customers are in place within the license. The 
full text of the license can be acquired from (OS 2006 BL). 

We make few assumptions about the "OS printer/copy shop license" to pursue building the Geo- 
license: 

• It covers certain datasets (CityModel) to which the print shop is entitled to provide services as 
described in the license. 

• instead of Ordnance survey receiving yearly royalties as stated in the license is running 
GeoDRM architecture as illustrated in chapter 3, and the compensation service can handle 
payment of royalties to OS in real-time or near real-time basis. 

• The OS license requires the licensed print shop to ask its customers to show the shop staff a 
valid paper license from OS to use its data. We assume the customer as well has a digital 
license issued from OS. 
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In this example we elaborate more on the GeoREL syntax to clarify the concept of the REL. the whole 
rights object (license) is enclosed between the "o-ex:rights" element pairs as we illustrated before. 
This constitutes the root element of the GeoREL rights instance as illustrated below. 

Declaring the rights object 

<o-ex:rights Attributes and namespaces used> 

<o-ex:context> 

<o-dd:version>1.0</o-dd:version> 
<o-dd:uid>RightsObject_UniqueIdentifier</o-dd:uid> 
<o-dd:name>OS Standard Printshop License</o-dd:name> 

</o-ex:context> 

Code Snippet 4-1 Declaring the rights object root element 

For the purpose of clarity the o-ex:rights above is missing the namespaces used in the license while 
they are listed in the license at (Appendix B). The o-ex:context element of the rights expression 
contains the version of the GeoREL, an o-dd:uid element at which OS places a unique rights object 
identifier that might pertain to certain numbering in there accounting systems. The purpose is to 
uniquely identify this license. And at last there is the formal name of the license in "o-dd:name" 
element. 

Defining the Assets in the Geolicense 

Below is the first major element defined within this license which is the Asset being licensed. In this 
case it's the CityModel dataset. In the unique identification of the Asset we used a DOI schema which 
was previously mentioned in chapter 3. The first part of the DOI (DOI: 10.1036) uniquely identifies 
OS as an entity. And the second part identifies this particular dataset. However based on the 
requirements datasets would be defined with geospatial boundaries. Hence we used the GeoREL 
context element "georel-dd:boundary" to define the gmhEnvelope containing the whole dataset. In 
this manner we have identified a spatial identifier of our asset. 



<o-ex:asset o-ex:id="a001"> 
<o-ex:context> 

<o-dd:uid>DOI:10.1036/CityModel-OSVector/0071369058</o-dd:uid> 
<georel-dd:Boundary> 

<georel-dd:DataSetBoundary> 
<gml:Envelope> 

<gml:lowerCorner>0 0</gml:lowerCorner> 
<gml:upperCorner>4 4</gml:upperCorner> 
</gml:Envelope> 
</georel-dd:DataSetBoundary> 
</georel-dd:Boundary> 
</o-ex:context> 
</o-ex:asset> 

Code Snippet 4-2 the Geolicense Asset Element 
Defining the Geolicense Agreement 

The initial step done was to define the asset covered under the agreement using the "o-ex:idref ' 
property which refers back to the asset declared above. Second was to define an agreement level 
constraint with the validity period of the agreement as 1 license year within the period defined by the 
OS license. 

<o-ex:agreement> 

<o-ex:asset o-ex:idref="a001"/> 
<o-ex:constraint> 

<o-dd:datetime> 
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<o-dd:start>2006-04-01T00:00:00</o-dd:start> 
<o-dd:end>2007-03-31T00:00:00</o-dd:end> 
</o-dd:datetime> 
</o-ex:constraint> 

Code Snippet 4-3 the agreement validity and which assets are covered 

The next step was to define the parties, between which this agreement is established, the first party 

below is OS. According to our assumptions established earlier OS receives payment of 40% of the 

transactions costs in royalties. Stemming from IPR concepts a party that has the rightsholder element 

is special types of party that can receive royalties as it hold rights to the licensed assets. The 

expression uses an "o-ex:container" element with an "ex-or" attribute which means an exclusive OR. 

This expression means that one of the two payment methods must be fulfilled either a minimum of 

47.5 euros or 40% of each transaction value. 

<o-ex:party> 
<o-ex:context> 

<o-dd:uid>x500:c=OS</o-dd:uid> 
<o-dd:role>PrimeLicensor</o-dd:role> 
</o-ex:context> 

<o-ex:rightsholder> 

<o-ex:container o-ex:type="in-or"> 
<odd:percentage>40</o-dd:percentage> 
<o-dd:fixedamount> 
<o-dd:payment> 
<o-dd:amount o-dd:currency="Euro">47.5</o-dd:amount> 
</o-dd:payment> 
</o-dd : fixedamount> 
</o-ex:container> 
</o-ex:rightsholder> 
</o-ex:party> 

Code Snippet 4-4 The first agreement party defined 

The second party involved is the Print-shop party which has rights over the assets constituting 60% of 
the amount of each transaction. 



<o-ex:party> 
<o-ex:context> 

<o-dd:uid>http://people.net/registry/ITC-PS-9999</o-dd:uid> 
<o-dd:role>PrintShop</o-dd:role> 
<o-dd:name>ITC Certified PrintShop</o-dd:name> 
</o-ex:context> 
<o-ex:rightsholder> 

<o-dd:percentage>60</o-dd:percentage> 
</o-ex:rightsholder> 
</o-ex:party> 

Code Snippet 4-5 the second agreement party defined 

After defining the parties we define the permissions, constraints and permission requirements for this 
particular agreement, which constitute the terms and conditions part of the license. The permission 
illustrated below starts by giving a "display" right. Then a "print" right, that has two constraints and 
two requirements. The first constraint "o-dd: printer" defines a trusted printer entity. In this scenario 
OS grants the shop the licenses to print only on this trusted printer. So that additional printers will 
always need to be registered with OS. The second constraint is a "papersize" constraint that only 
permits printing on A6 paper. For this permission to be valid, the requirements must be fulfilled. The 
requirements are provided with a sequence "o-ex: sequence" to suggest certain ordering in the flow, 
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first the print-shop needs to have it' s customers providing an "InternalBusinessUse" license issued to 

them from OS. Second .28 euros are paid per print as well as a 5% tax. 

<o-ex:permission> 

<o-dd:display/> 
</o-ex:permission > 
<o-ex:permission> 
<o-dd:print> 

<o-ex:constraint> 

<o-dd:printer o-ex:id="p001 "> 
<o-ex:context> 

<o-dd:uid>guid:TrustPrint/4747474742222</o-dd:uid> 
</o-ex:context> 
</o-dd:printer> 
<georel-dd:papersize georel-dd:pSize="A6'7> 
</o-ex:constraint> 
<o-ex:requirement> 
<o-ex:sequence o-ex:order="total"> 
<o-ex:seq-item o-ex:number=" 1 "> 
<georel-dd:checkuserlicensetype> 
<georel-dd:IntemalBusinessUse/> 

</georel-dd:checkuserlicensetype> 
</o-ex:seq-item> 
<o-ex:seq-item o-ex:number="2"> 
<o-dd:peruse> 
<o-dd:payment> 

<o-dd:amount o-dd:currency="Euro">.28</o-dd:amount> 
<o-dd:taxpercent o-dd:code="VAT">5</o-dd:taxpercent> 
</o-dd:payment> 
</o-dd:peruse> 
</o-ex:seq-item> 
</o-ex:sequence> 
</o-ex:requirement> 
</o-dd:print> 
</o-ex:permission> 

Code Snippet 4-6 Print-shop agreement permission 

In this example we have illustrated how to model a license to the Developed GeoREL and have 
provided illustration to many aspects including and the city model vector dataset is represented with 
spatial properties in the Geolicense. The details of the Geolicense are attached as Appendix B. 

4.4.2. Feature level license 

In the previous example, we illustrated how the print/copy shop license was presented; at this section, 
we illustrate a complementary license to the previous example. Based on the assumption made earlier 
on, the print/shop customer needs to provide the print-shop with a valid OS license OS can now issues 
customers digital licenses specifying areas of coverage and certain features or dataset layers. These 
licenses can be presented by the customer to the print-shop online or offline to authorize the requested 
prints for each customer. 
Defining the Assets in the Geolicense 

The asset element below follows (code snippet 4-7) a similar method to define the CityModel dataset 
boundaries. However for this license the OS customer has rights only over feature types of StreetType 
and IntersectionType features. Using the method defined in section 4.3 to express rights on the feature 
level we used the developed "georel-dd:gmlfeature" element to describe the two featureTypes as 
illustrated below, The <georel-dd:appschemaElement xsi:type="am:StreetType"/> element defines 
"am: StreetType" which all the streets in the CityModel dataset are part of. 
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<o-ex:asset o-ex:id="a001"> 
<o-ex:context> 

<o-dd:uid>DOI:10.1523/OSVector.3721-05.2006</o-dd:uid> 
<georel-dd:Boundary> 

<georel-dd:DataSetBoundary> 
<gml:Envelope> 

<gml : lo werCorner>0 0</gml : lo werCorner> 
<gml : upperCorner>4 4</gml : upperCorner> 
</gml:Envelope> 
</georel-dd:DataSetBoundary> 
</georel-dd:Boundary> 
<georel-dd:gmlfeature> 

<georel-dd:appschemaElement xsi:type="am:StreetType"/> 
</georel-dd:gmlfeature> 

<georel-dd : gmlfeature> 

<georel-dd:appschemaElement xsi:type="am:IntersectionType"/> 
</georel-dd : gmlfeature> 
</o-ex:context> 
</o-ex:asset> 

Code Snippet 4-7 The Geolicense asset element 
Defining the Geolicense Agreement 

In this sections we don't focus on the agreement element as it's following the same method in the 

previous example, thus we focus on the permissions, constraints and the requirements. In the 

permission blow we grant permission over the previously defined assets with this statement <o- 

ex:asset o-ex:idref="a001"/> . We then define spatial permissions such as "extractFeature" and 

"CoordinateOperation". Since this license can as well be used by the OS customer to request printing 

at a certified print shop the "print" permission is described as the previous example, however in this 

example the we describe a constraint on the feature with the feature "ID=S1" in the CityModel 

instance. By using the same construct to define the assets above <georel-dd:appschemaElement 

xsi:type="am:StreefType" gml:id="Sl"/> and adding the feature ID at the element property of type 

gmhid we specified a specific feature within the streetType features by using the feature ID. This 

license requires the prepayment of the specified amount once a year in the validity of the license. For 

the detailed license instance refer to (Appendix D) 

<o-ex:permission> 

<o-ex:asset o-ex:idref="a001'7> 

<georel-dd:coordoperation o-ex:id="c001"> 
<georel-dd:coopID> 

<gml : name>CTrans 1 </gml : name> 
</georel-dd:coopID> 
</georel-dd:coordoperation> 
<georel-dd:extractfeature o-ex:id="e001 "/> 
<georel-dd:spatialoperator o-ex:id="s001'7> 
<o-dd:print o-ex:id="p001"> 
<o-ex:constraint> 
<o-ex:context> 

<georel-dd : gmlfeature> 

<georel-dd:appschemaElement xsi:type="am:StreetType" gml:id="Sl'7> 
</georel-dd:gmlfeature> 
</o-ex:context> 

<georel-dd:papersize georel-dd:pSize="A3'7> 
<georel-dd:printresolution georel-dd:pRes="AU'7> 
</o-ex : constraint 
</o-dd:print> 
<o-dd:duplicate/> 
<o-dd:display o-ex:id="d001'7> 
<o-dd:watermark/> 
<o-ex : requirement> 
<o-dd:prepay> 
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<o-dd:payment> 




<o-dd:amount o-dd:currency= 


="Euro">3500</o-dd:amount> 


<o-dd:taxpercent o-dd:code= 


'VAT">5</o-dd:taxpercent> 


</o-dd:payment> 




</o-dd:prepay> 




</o-ex:requirement> 




</o-ex:permission> 





Code Snippet 4-8 The Geolicense spatial permissions 



4.4.3. Print-shop Preview GeoLicense 

The last example we a simple preview license (Appendix C) where the licensee can re -grant the rights 

to others for the purpose of previewing the same dataset. Explained below is the developed "georel- 

dd" regrant permission. The "o-dd:transferrPerm" element allows the licensee to "re-grant" the 

permissions listed in three distinct moods define by the "o-dd:downstream" property. The value" 

equal" for this property allow for the same permissions only to be transferred (i.e. display and print 

must be granted) while a if the "o-dd:downstream" attribute had the value "less" then the permissions 

re-granted to sublicensees must be less than the permissions listed in the original license. If the 

attribute had the value "notgreater" then it means not less than or equal to the permissions listed in the 

license. According to this license, the licensee can give other users the permissions to preview the 

CityModel dataset, and it can be printed twice on A4 paper, with a watermark on the background. 

<o-ex:permission> 

<georel-dd : regranO 

<o-dd:transferPermo-dd:downstream="equal"> 
<o-dd:display o-ex:idref="p001 "/> 
<o-dd:print o-ex:idref="p002"/> 
</o-dd:transferPerm> 
</georel-dd:regrant> 
</o-ex:permission> 

Code Snippet 4-9 The Geolicense spatial permissions 

4.5. Conclusions 

In this chapter, we have provided a proof of concept for the GeoREL. The examples have shown that 
the approach developed can accommodate the major requirements of geospatial rights expression. We 
have demonstrated the ability to specify boundaries or licenses, as well as spatial and non-spatial 
permissions. In addition, the capability to express features and feature collection level permissions 
was demonstrated. Using Ordnance Survey license scenario we illustrated that ODRL and RELs in 
general provide a mechanisms to express contractual agreements. In chapter 3, we have listed five 
general requirements of the GeoREL. One requirement that is the composite licenses we addressed 
that is out of the scope of this research. The four remaining requirements and a brief description of 
how we resolved them is enumerated below 

1. Rights Granularity: through the element <georel-dd:appSchemaElemet> we were able to 
specify rights on various granularities. On a single feature level, and feature collection as well 
as feature types, examples of it's use is illustrated in section 4.4.2 

2. Spatial extent of licenses: we have implemented a <georel-dd:Boundary> element and 
illustrated how this can be used to express spatial extents of licenses. Examples of it's use are 
illustrated in section 4.4.1 through 4.4.3 

3. Types of Permissions: we have implemented various spatial permissions as illustrated in 
figure 4-3. examples of there use are illustrated in section 4.4.2 
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4. Administration rights: for this particular proof of concept we have implemented one 
administration right which is the <georel-dd:regrant> to enable regranting of the rights by 
licensors to sublicenses and demonstrated an example of its use in section 4.4.3. In 
conjunction with the standard ODRL element <o-dd:downstream> regrant can be used to 
control the flow of IPR downstream in the value chain in the moods illustrated in section 
4.4.3. 

The Geospatial extension of RELs means that a REL maintains the same inherent capabilities in 
describing contractual agreements while providing the facilities essential to express contracts over 
geospatial assets (Geolicenses). In section 1.2 we addressed the research context. The above 
requierements listed satisify the frame of the research context main aspects regarding specifying 
assets with the geolicense as part from a continous larger whole such as geospatial datasets (i.e. as 
opposed to discreet assets like books). As well as the ability to specify, clear terms and conditions on 
the geospatial assets, which are inherently non-discreet. 

This approach extending ODRL can be used to extend other RELs. In chapter 3, we have listed five 
general requirements of the GeoREL. 

In the next chapter, we address the conclusions, recommendations, and future work stemming from 
this research 
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5. Conclusions and Recommendations 



5.1. Introduction 

The main objective of this research was to develop an approach for the expression of digital licenses 
on GML datasets. To achieve this objective we first needed further understanding of GeoDRM scope 
and the technologies that support the GeoDRM framework. Since GeoDRM is a novel topic we have 
followed top down approach to the problem by defining GeoDRM. We proposed a GeoDRM 
reference architecture, developed a GeoDRM information model and finally we proposed an approach 
for the expression of digital licenses for GML. 

This research was conducted in three phases. The goal of the first phase was to understand GeoDRM 
scope and technology as an initial step to position this research within the larger picture of GeoDRM. 
We have studied definitions of DRM and the general components of DRM. During this study, it was 
found that DRM has technical and legal frameworks which are integral part of a DRM policy. We 
then mapped the findings from the general DRM framework to GeoDRM; we then examined the 
current licensing in the geospatial domain as the dominant mode for dissemination of IPR. We finally 
concluded this phase by defining GeoDRM spectrum and further narrowed down the scope of this 
research within the digital licensing as an integral part of GeoDRM. 

In the second phase we examined relevant DRM technologies that are employed for digital licensing. 
The findings were then mapped into the GeoDRM reference architecture which we proposed in 
chapter 3. We then established the GeoDRM information model and elaborated on each of the 
elements of the information model in section 3.4. A general set of requirements for the digital 
licensing of GML datasets were then identified 3.5 and the geolicense model was introduced in 
section 3.6. This model adopts the relevant IPR semantics from the ODRL (open digital rights 
language). 

In the last phase we designed the ODRL extension to build a GeoREL that is capable of expressing 
geolicenses and illustrated the process used to extend the ODRL REL. a proof of concept was 
conducted using scenarios derived from Ordnance Survey "Print/Copy shop license" to illustrate the 
use of the proposed GeoREL. 

5.2. Achieved results against Research outline 

In this section we review the achieved results of this research against the objectives and research 
questions stated in chapter 1 as the basis for the general conclusions. Recommendations and future 
research are then presented in section 5.3.1 5.3.2 respectively. 
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• Define the elements of GeoDRM framework 

1. What is DRM and how is it different from seemingly similar fields like access 
control? 

It was found that DRM is for the management of rights over digital assets (see 
section 2.3). An asset is defined in the Webster dictionary as "an item of value 
owned". In the realm of Service Oriented Architecture (SOA), an organization can 
own the rights to a service rather than digital content. Other researchers asserted a 
general similarity between DRM and access control, however we defined this 
similarity to be rather from a technical perspective. Access control defines policies 
that govern parties that are allowed to access assets. DRM is however 
fundamentally different in that it stems from intellectual property rights (IPR) 
dealing with the ownership of the assets. Digital licenses in DRM are legal 
contracts governing the dissemination of IPR. We concluded that DRM always 
consists of a technical aspect and a policy aspect that is manifested in the form of 
legal contractual agreements that are further under effect by the statutory IPR laws 
(see section 2.4). It is therefore important to realize that DRM systems are 
combination of technical and legal measures employed to control the 
dissemination of IPR. 

2. How are Geospatial Intellectual property rights currently being disseminated? 

In section 2.4 we illustrated the formal relationship between IPR, Laws and 
contractual law (licensing). Important assertions were made regarding the 
relationship which assisted us in better understanding the role of DRM. We then 
mapped our findings to the geospatial community and concluded that licensing is 
the common means of dissemination of IPR in the geospatial domain community. 
However the complexity of defining licensed rights stems from the fact that 
licensing rights are a reconciliation of two often contradicting rulings, 

• The statutory rights granted by the IPR laws (e.g. copyrights) 

• And the permissions on assets granted as licensed rights in licenses. 

We have concluded that licensed rights could grant narrower or wider (copyleft) 
set of rights to licensees than originally permitted by copyrights laws. And that 
licensing of geospatial content doesn't relinquish the protection provided by IPR 
laws unless stated in the licenses. 

3. Why GeoDRM is needed in today's geospatial data sharing environments? 

GeoDRM is driven by market needs, we have looked briefly into forces leading to 
the emergence of GeoDRM like the vision for a geospatial market place, INSPIRE 
and ordnance survey's online business models. From section 2.4 and 2.5 we 
concluded that the need stems from the widespread use of web-based geospatial 
services and the effects of digital environments on data sharing where geospatial 
providers face the need to control the dissemination of IPR downstream in the 
value chain. 
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4. What is the definition and scope of GeoDRM? 

• GeoDRM can mean different set of technologies in different situations (see 
section 2.5). Ordnance survey uses click-thorough, and OGC implemented click- 
through mechanisms for the Web map server. 

• Digital licensing as addressed in this thesis is a form of GeoDRM 

• Watermarking, encryption, and enforced contracts are all degrees of GeoDRM 
that can be combined together with legal frameworks to form IPR dissemination 
policies. 

• It' s not practical to define GeoDRM as a single technology. Rather, its better be 
defined through the GeoDRM spectrum where new technologies are added to the 
spectrum as it emerges from user needs. 

• GeoDRM can be defined as a set of technologies and legal frameworks that are fit 
to a certain organizational need, forming a GeoDRM policy for enabling rights 
managed geospatial networks (e.g. SDIs) where all rights over geospatial assets 
are specified by the licensors. 

• We have identified the role of trust in GeoDRM. As parties involved in geospatial 
sharing, transactions become recognized and agreements are guaranteed to be 
expressed and honored establishing trust between entities serves as an important 
role in ensuring the success of the system. 

• To develop a high level reference architecture for GeoDRM digital licensing 

5. How digital licensing of assets is managed on web environments? 

In section 3.2 we addressed the DRM reference architecture. We asserted that the 
architecture is content centric as well as it doesn't illustrate more details on what are 
the services needed for management of digital license instances. The DRM licensing 
infrastructure was then presented as the latest development in management of digital 
licensing that focuses on licensing of assets as defined in this thesis (i.e., content and 
services). We also illustrated the array of services provided and there roles. 

6. What are the components of the GeoDRM reference architecture? 

In section 3.3 we introduced the GeoDRM architecture which is composed of five 
major services. These are Negotiation service, digital rights service, compensation 
service, service level agreement service and the administrative GeoDRM service. 
The GeoDRM gateway handles the delegation of requests to services. In three UML 
sequence diagrams we illustrated three main scenarios involving the architecture. 
The goal was to illustrate the sequence of interaction between major services. The 
scenarios cover the main activities in web access of geospatial data. The scenarios 
are acquiring license first and dataset later, acquire dataset first and license later, 
acquire license and dataset combined. This architecture is a high level architecture 
for GeoDRM digital licensing. 

• Define a General GeoDRM Information model. 
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7. How can we develop a GeoDRM reference information model and what are the 
components of the GeoDRM reference information model? 

In section 3.4 we studied the major components of a DRM information model. We 
have not been able to find a particular DRM information model since such model is 
somehow arbitrary and domain dependant. Figure 3-9 illustrates the UML model of 
the GeoDRM information model, and subsequent sections elaborated on the meaning 
and role of each of the element in the model. In this research we have established the 
information model and we asserted that RELs are the means of building instances of 
this information model. In this work we only addressed the expression of rights over 
spatial assets. 

• To identify an appropriate method to describe contractual agreements for licensing of 
geospatial digital content via a rights expression language and develop an extension to 
an existing licensing standard as a proof of concept. 

8. What are the general requirements of geospatial rights expression on GML datasets? 

To answer this question we put forward a hypothesis based on our understanding of 
the GeoDRM architecture and on how licenses are being used. Combining this 
understanding with the information drawn from the GeoDRM information model 
and the granular nature of GML (feature level, feature collections, spatial and non 
spatial properties of features), we identified a general set of high level requirements 
that would guide a development of a proof of concept to validate the proposed 
rights expression approach. 

9. How do we accommodate the above requirements in existing Rights expression 
languages? 

• To answer this question a novel approach was proposed to extend existing REL 
with Geospatial capabilities. In section 3.6 we concluded on the GeoDRM 
information model and the requirements with the geolicense model. One of the 
finding of this research is that modelling a digital license needs to be done inline 
with a certain rights expression language. The reason for this particular point is 
that RELs provide semantics and vocabulary for expression IPR concepts. Hence 
utilizing the basic information model of the ODRL (open digital rights language) 
we proposed a geolicense model which is illustrated in figure 3-12. The 
geolicense model uses ODRL semantics for expressing the relations between the 
assets, agreements, parties, and permissions, while the model is extended with 
spatial permissions and spatial constraints, as well as spatial properties to assist 
in expressing the assets. 

• The approach uses The GML schema to build spatial data types within the 
ODRL language which enabled the expression of spatial properties within the 
geolicense. 

• ODRL consists of a data dictionary schema and a rights expression schema. A 
new spatial data dictionary has been developed to accommodate the 
requirements of the Geolicense as sown in chapter 4. 
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• The approaches have been validated using, Altova XML spy due to lack of 
GeoDRM technology implementations. License scenarios emulating the 
Ordnance survey Print/shop license have been modeled assuming OS is issuing 
digital licenses to its customers. The functionality of the developed schema in 
expression of geolicenses on GML datasets has been demonstrated. 

5.3. Recommendations and Future Work 

Some recommendations are drawn from this research regarding GeoDRM digital licensing and 
GeoDRM in general. 

5.3.1. General research recommendations 

• Harmonized licensing frameworks are an essential step towards a GeoDRM policy in GI 
organizations. This stems from our finding in DRM related fields, INSPIRE initiative seeks to 
develop harmonized licensing frameworks as an initial step towards employing click-through 
licensing mechanisms for the data themes covered within the initiative. 

• Due to the time limitations and the problems encountered to conduct field work we haven't 
been able to conduct an active requirements analysis for a certain organizational situation. 
However it is recommended that a detailed study be carried out across various organizations 
(ordnance survey, Dutch cadastre, etc..) and geospatial data sharing settings (e.g. INSPIRE, 
NRW, GeoConnections, etc..) to gather a wider set of requirements regarding a wide range of 
stakeholder needs. 

• It is recommended that modelling of geolicenses be done with respect to a certain rights 
expression language to benefit from the inherent IPR semantics within the rights expression 
language. 

• The usage of GML schema into the developed REL schema provided efficient means for 
building spatial data types. Hence this approach is recommended when considering the 
extension of RELs to enable expressing geolicenses. 

5.3.2. Future Work 

• GeoDRM has legal and technology aspects. A GeoDRM policy is country specific and must 
use legal and technical means to achieve its goals. Further research into both aspects must 
define the country specific guidelines for developing integrated legal and technical measures 
of implementing GeoDRM. 

• Study how digital licensing and other GeoDRM technologies will affect business models of 
GI organizations. 

• Study how to build business models that leverage GeoDRM technologies to fully benefit from 
online web-based geospatial data sharing. 

• (Francis Harvey, 2003; Francis Harvey et al., 2004) stresses the importance of trust as an 
element in defining geospatial data sharing patterns. Understanding trust and its effects is 
important in building GeoDRM systems. For example does higher trust entail lower security 
measures on GeoDRM systems? And how can the concept of trust leverage on GeoDRM' s 
ability to unambiguously define liabilities and duties of parties involved in data sharing. 

• Each of the elements within the GeoDRM information model needs further study. For 
example: 
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• To derive a full fledged geospatial rights model further analysis is needed across 
various organizations to define the set of rights within each of the categories 
(render rights, transport rights, derivative work rights and administrative rights). 

• Methods for Unique identification information needs to be researched this 
includes; unique identification of assets (individual datasets and services), 
parties and right holders, as well as digital license instances. 

• Trust information is an important aspect of research. Identifying what 
information constitutes the GeoDRM trust model is an essential research step. 
Also which elements and information needs to be shared about the parties to 
increase trust in the GeoDRM framework (e.g. Quality, provenance of 
transactions for participating parties etc. . . ) 

• Asset protection information and techniques are another area of research. 
Watermarking, fingerprinting and encryption can be combined with various 
measures of protection to serve a myriad of business models. Watermarking of 
geospatial datasets is a new area of research specially watermarking of vector 
datasets which so far have received less attention than raster datasets 
watermarking. 

• This research focused on the expression of digital licenses using RELs on GML datasets, no 
further research was conducted on the enforcement of rights. Further study on enforcement of 
geolicenses is needed. 

• This research focused only on GML vector data. Further research is needed to provide a 
GeoDRM capability on Map data and coverages as well as other data formats (e.g. shape 
files). 

• GML is mainly used as a mechanism to encode geospatial datasets for exchange. How do we 
maintain the mapping between GML datasets and their respective licenses after they are 
imported into a client's database? Many questions would arise in this area of research that 
would also have profound effects on persistent enforcement of digital licenses. 

• Since digital licenses contain information about the spatial assets (e.g. boundaries) could 
these licenses be used as service access tickets? (e.g. do we need a "GetFeature" permissions 
on a WFS or is it sufficient to send the license which constitutes an implicit "GetFeature" 
Request) this allows users to send licenses to services which would then release datasets 
accordingly, licenses would also be used to enforce the rights on the client machine. 

• Extending current metadata standards and the OGC CSW service to accommodate the rights 
metadata needed as discussed in section 3.4.1.4. Also establishing a GeoDRM product 
catalogue to enable expression of generalized licensing frameworks on certain assets as 
products which enable the negotiation service to negotiate licenses on assets based on these 
generalized licensing schemas. 
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• In section 3.5 we addressed the need to construct semantically correct licenses (or 
permissions decisions) out of a set of heterogeneous licenses over a certain asset or part of an 
asset when combining datasets. We stated that resolving this issue is outside the scope of this 
research. We believe that Ontologies and Rules (Web Ontology Language, OWL, and 
Semantic Web Rule Language SWRL) will enable us to provide reasoning capabilities to 
resolve conflicts in a stack of licenses. 

• Research and development in building the GeoDRM architecture services is an essential step 
to enable testing of the technical work and the theoretical concepts developed in GeoDRM 
research. 
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Appendix (A): The Developed GeoREL 
Schema 

■ The schema file supplied on CD with this thesis is GeoREL-DD.xsd 

<?xml version="1.0" encoding="UTF-8"?> 

<!-- edited with XMLSpy v2006 spl U (http://www.altova.com) by Mohamed Bishr (EMBRACE) --> 
<!-- Mohamed Bishr All Rights Reserved 2006-3- 3-> 

<xsd:schema xmlns:xsd="http://www. w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml" xmlns:o- 
ex="http://odrl.net/l . 1/ODRL-EX" xmlns:o-dd="http://odrl.net/l . 1/ODRL-DD" xmlns:am="http://www.in.tum.de/am" 
xmlns:georel-dd="http://example.net/georel-dd" targetNamespace="http://example.net/georel-dd" 
elementFormDefault="qualified" attributeFormDefault="qualified" version=" 1 . 1 "> 
<xsd:annotation> 

<xsd:documentation> 

<version>l .0.0</version> 

<copyright>Copyright (c) 2005-2006 Mohamed Bishr, ITC, All Rights 

Reserved</copyright> 

</xsd :documentation> 
</xsd : annotation> 
<!-List Of Imports~> 

<xsd:import namespace="http://odrl.net/l. 1/ODRL-EX" schemaLocation="http://www.odrl.net/l. 1/ODRL-EX - 



<xsd:import namespace="http://odrl. net/1. 1/ODRL-DD" schemaLocation="http://www.odrl. net/1. 1/ODRL-DD- 



ll.xsd"/> 
ll.xsd"/> 

<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="C:\Documents and SettingsMvIohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\Base\feature.xsd"/> 

<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="C:\Documents and SettingsMvIohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\Base\coordinateReferenceSystems.xsd"/> 

<xsd:import namespace="http://www.in.tum.de/am" schemaLocation="C:\Documents and SettingsVMohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\CityModel\CityModel.xsd"/> 

<!-GRELSchema-> 

<!— declare new GeoREL datatypes— > 

<!-gml boundary to define the dataset boundaries in the context element of any entity specially asset entity~> 
<xsd:complexType name="gmlBoundary"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:contextType"> 
<xsd:sequence> 

<xsd:element name="DataSetBoundary" 

type="gml:BoundingShapeType" minOccurs="0"/> 

</xsd:sequence> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!- Defining this datatype makes it possible to specifiy application schema features in a rights expression n the 
context extity like in an asset element for exmaple— > 

<xsd:complexType name="gmlappSchema"> 
<xsd:annotation> 

<xsd:documentation> 
datatype is used to construct a context element of Type gmkAbstractFeatureType. 
</xsd:documentation> 

</xsd:annotation> 
<xsd:complexContent> 

<xsd:extension base="o-ex:contextType"> 
<xsd:choice> 

<xsd: element name= " app schemaElement" 

type="gml:AbstractFeatureType"/> 

</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd : complexTypo 

<!— define a datatype to be used to specify Coordinateoperation using a gml Type to make it possible to specify 
same operation defined in GML— > 
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<xsd:complexType name="CoordinateOperation"> 
<xsd : complexContent> 

<xsd:extension base="o-ex:permissionType"> 
<xsd:choice> 

<xsd:element name="coopID" type="gml:IdentifierType"/> 
</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!~deflne a datatype to be used to specify new requierements— > 
<xsd:complexType name="customerlicense"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:requirementType"> 
<xsd:choice> 

<xsd:element name="InternalBusinessUse" type="xsd:string" 

minOccurs="0"/> 

<xsd:element name="other" type="xsd:string" minOccurs="0"/> 
</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!— define new datatypes to be used for a specific variation of print constraints— > 
<xsd:complexType name="printResType"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:constraintType"> 

<xsd:attribute name="pRes" default="200dpi"> 
<xsd:simpleType> 

<xsd:restriction base="xsd:NMTOKEN"> 

<xsd:enumeration value="200dpi"/> 
<xsd:enumeration value="300dpi"/> 
<xsd:enumeration value="600dpi"/> 
<xsd:enumeration value="AH"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<xsd:complexType name="printPaperType"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:constraintType"> 

<xsd: attribute name="pSize" default="A4"> 
<xsd:simpleType> 

<xsd:restriction base="xsd:NMTOKEN"> 
<xsd:enumeration value="A6"/> 
<xsd:enumeration value="A5"/> 
<xsd: enumeration value='A4"/> 
<xsd: enumeration value='A3"/> 
<xsd:enumeration value='A2"/> 
<xsd:enumeration value='Al"/> 
<xsd:enumeration value='A0"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!— Declare New Requirement elements— > 

<xsd:element name="checkuserlicensetype" type="georel-dd:customerlicense" substitutionGroup="o- 
ex : requirementElement "/> 

<!— Declare New Permession elements— > 

<!— A permission to grant other permession as opposed to sell, move etc... — > 

<xsd:element name="regrant" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<xsd:element name="coordoperation" type="georel-dd:CoordinateOperation" substitutionGroup="o- 
ex:permissionElement"> 

<xsd:annotation> 
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<xsd:documentation>this element describes a coordinate operation permissions which uses 
gmkidentifierType to describe the operation name equivalent to the GML application schema</xsd:documentation> 
</xsd:annotation> 
</xsd:element> 

<xsd:element name="geometryconversion" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="qualitativeoperations" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="quantitativeoperations" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="newgeometry" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<xsd:element name="spatialoperator" type="o-ex:permissionType" substitutionGroup="o- 

ex:permissionElement"/> 

<xsd:element name="spatialrelation" type="o-ex:permissionType" substitutionGroup="o- 

ex:permissionElement"/> 

<xsd:element name="extractfeature" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<!-- Declare New Context elements-> 

<!- to decalre geometric boundaries within a given context specially in the asset element representing whole 

datasets-> 

<xsd:element name="Boundary" type="georel-dd:gmlBoundary" substitutionGroup="o-ex:contextElement"/> 
<xsd:element name="gmlfeature" type="georel-dd:gmlappSchema" substitutionGroup="o-ex:contextElement"/> 
<!— Declare new Constraint Elemnts— > 

<xsd:element name="printresolution" type="georel-dd:printResType" substitutionGroup="o- 
ex:constraintElement"/> 

<xsd:element name="papersize" type="georel-dd:printPaperType" substitutionGroup="o-ex:constraintElement"/> 
<!-- create new condition elements-> 

<!-- <xsd:element name="commercial " type="georel-dd:CoordinateOperation" substitutionGroup="o- 
ex:permissionElement"/>-> 
</xsd:schema> 



Data Dictionary Semantics 



DD vocabulary 


Semantics 


checkuserlicensetype 


This element is used as a requirement where users need to apply a valid 
license to the print-shop to request print services. 


regrant 


This is a permissions to grant certain permissions as specified within it for 
other sub-licensees 


Coordoperation 


This is a permission to perform a certain coordinate operation (e.g. 
coordinate transformation) as named using the gmhname property of this 
element. 


Geometryconversion 


Is a permissions to generalize for example from polygon to centerline in a 
road feature db 


Qualitativeoperations 


Permission element to do qualitative operations, these are mostly 
topological, like give me all features on the right side of this road segment 


Quantitativeoperation 

s 


Permission element to do quantitative operation and are operations that 
involve computation, buffering, intersect 


extractfeature 


Permission element to extract features from a certain dataset 


Spatialrelation 


Is a qualitative operation to allow querying based on topological relations 


Spatialoperator 


Permission element to do spatial operators which are those spatial 
operations that generate a new feature 


Boundary 


Is a context Element to specify the boundaries of a dataset. 


gmlfeature 


Is a context element to specify features, Feature Type, and feature 
collection level elements 
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Printerresolution 


An element to specify the resolution of printing. 


Papersize 


An element to specify the size of paper 
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Appendix (B): License Scenario 4.4.1 
XML instance 

■ The schema file supplied on CD with this thesis is PrintShop.xml 

<?xml version="1.0" encoding="UTF-8"?> 

<!-- edited with XMLSpy v2006 spl U (http://www.altova.com) by Mohamed Bishr (EMBRACE) --> 
<!-- Mohamed Bishr All Rights Reserved 2006-3- 3-> 

<xsd:schema xmlns:xsd="http://www. w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml" xmlns:o- 
ex="http://odrl.net/l . 1/ODRL-EX" xmlns:o-dd="http://odrl.net/l . 1/ODRL-DD" xmms:am="http://www.in.tum.de/am" 
xmlns:georel-dd="http://example.net/georel-dd" targetNamespace="http://example.net/georel-dd" 
elementFormDefault="qualified" attributeFormDefault="qualified" version=" 1 . 1 "> 
<xsd:annotation> 

<xsd:documentation> 

<version>l .0.0</version> 

<copyright>Copyright (c) 2005-2006 Mohamed Bishr, ITC, All Rights 

Reserved</copyright> 

</xsd:documentation> 
</xsd : annotation> 
<!-List Of Imports~> 

<xsd:import namespace="http://odrl.net/l. 1/ODRL-EX" schemaLocation="http://www.odrl.net/l. 1/ODRL-EX - 



<xsd:import namespace="http://odrl. net/1. 1/ODRL-DD" schemaLocation="http://www.odrl. net/1. 1/ODRL-DD- 



ll.xsd"/> 
ll.xsd"/> 

<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="C:\Documents and SettingsMvIohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\Base\feature.xsd"/> 

<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="C:\Documents and SettingsMvIohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\Base\coordinateReferenceSystems.xsd"/> 

<xsd:import namespace="http://www.in.tum.de/am" schemaLocation="C:\Documents and SettingsVMohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\CityModel\CityModel.xsd"/> 

<!-GRELSchema-> 

<!— declare new GeoREL datatypes— > 

<!-gml boundary to define the dataset boundaries in the context element of any entity specially asset entity~> 
<xsd:complexType name="gmlBoundary"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:contextType"> 
<xsd:sequence> 

<xsd:element name="DataSetBoundary" 

type="gml:BoundingShapeType" minOccurs="0"/> 

</xsd:sequence> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!- Defining this datatype makes it possible to specifiy application schema features in a rights expression n the 
context extity like in an asset element for exmaple— > 

<xsd:complexType name="gmlappSchema"> 
<xsd:annotation> 

<xsd:documentation> 
datatype is used to construct a context element of Type gmkAbstractFeatureType. 
</xsd:documentation> 

</xsd:annotation> 
<xsd:complexContent> 

<xsd:extension base="o-ex:contextType"> 
<xsd:choice> 

<xsd: element name= " app schemaElement" 

type="gml:AbstractFeatureType"/> 

</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd : complexTypo 

<!— define a datatype to be used to specify Coordinateoperation using a gml Type to make it possible to specify 
same operation defined in GML— > 
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<xsd:complexType name="CoordinateOperation"> 
<xsd : complexContent> 

<xsd:extension base="o-ex:permissionType"> 
<xsd:choice> 

<xsd:element name="coopID" type="gml:IdentifierType"/> 
</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!~deflne a datatype to be used to specify new requierements— > 
<xsd:complexType name="customerlicense"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:requirementType"> 
<xsd:choice> 

<xsd:element name="InternalBusinessUse" type="xsd:string" 

minOccurs="0"/> 

<xsd:element name="other" type="xsd:string" minOccurs="0"/> 
</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!— define new datatypes to be used for a specific variation of print constraints— > 
<xsd:complexType name="printResType"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:constraintType"> 

<xsd:attribute name="pRes" default="200dpi"> 
<xsd:simpleType> 

<xsd:restriction base="xsd:NMTOKEN"> 

<xsd:enumeration value="200dpi"/> 
<xsd:enumeration value="300dpi"/> 
<xsd:enumeration value="600dpi"/> 
<xsd:enumeration value="AH"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<xsd:complexType name="printPaperType"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:constraintType"> 

<xsd: attribute name="pSize" default="A4"> 
<xsd:simpleType> 

<xsd:restriction base="xsd:NMTOKEN"> 
<xsd:enumeration value="A6"/> 
<xsd:enumeration value="A5"/> 
<xsd: enumeration value='A4"/> 
<xsd: enumeration value='A3"/> 
<xsd:enumeration value='A2"/> 
<xsd:enumeration value='Al"/> 
<xsd:enumeration value='A0"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!— Declare New Requirement elements— > 

<xsd:element name="checkuserlicensetype" type="georel-dd:customerlicense" substitutionGroup="o- 
ex : requirementElement "/> 

<!— Declare New Permession elements— > 

<!— A permission to grant other permession as opposed to sell, move etc... — > 

<xsd:element name="regrant" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<xsd:element name="coordoperation" type="georel-dd:CoordinateOperation" substitutionGroup="o- 
ex:permissionElement"> 

<xsd:annotation> 
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<xsd:documentation>this element describes a coordinate operation permissions which uses 
gmkidentifierType to describe the operation name equivalent to the GML application schema</xsd:documentation> 
</xsd:annotation> 
</xsd:element> 

<xsd:element name="geometryconversion" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="qualitativeoperations" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="quantitativeoperations" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="newgeometry" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<xsd:element name="spatialoperator" type="o-ex:permissionType" substitutionGroup="o- 

ex:permissionElement"/> 

<xsd:element name="spatialrelation" type="o-ex:permissionType" substitutionGroup="o- 

ex:permissionElement"/> 

<xsd:element name="extractfeature" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<!-- Declare New Context elements-> 

<!- to decalre geometric boundaries within a given context specially in the asset element representing whole 

datasets-> 

<xsd:element name="Boundary" type="georel-dd:gmlBoundary" substitutionGroup="o-ex:contextElement"/> 
<xsd:element name="gmlfeature" type="georel-dd:gmlappSchema" substitutionGroup="o-ex:contextElement"/> 
<!— Declare new Constraint Elemnts— > 

<xsd:element name="printresolution" type="georel-dd:printResType" substitutionGroup="o- 
ex:constraintElement"/> 

<xsd:element name="papersize" type="georel-dd:printPaperType" substitutionGroup="o-ex:constraintElement"/> 
<!-- create new condition elements-> 

<!-- <xsd:element name="commercial " type="georel-dd:CoordinateOperation" substitutionGroup="o- 
ex:permissionElement"/>-> 
</xsd:schema> 



GEOSPATIAL DIGITAL RIGHTS MANAGEMENT 



Appendix (C): License Scenario 4.4.2 
XML instance 

* The schema file supplied on CD with this thesis is FTypeLevelLicensexml 

<?xml version="1.0" encoding="UTF-8"?> 

<!-- edited with XMLSpy v2006 spl U (http://www.altova.com) by Mohamed Bishr (EMBRACE) --> 
<!-- Mohamed Bishr All Rights Reserved 2006-3- 3-> 

<xsd:schema xmlns:xsd="http://www. w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml" xmlns:o- 
ex="http://odrl.net/l. 1/ODRL-EX" xmlns:o-dd="http://odrl.net/l . 1/ODRL-DD" xmlns:am="http://www.in.tum.de/am" 
xmlns:georel-dd="http://example.net/georel-dd" targetNamespace="http://example.net/georel-dd" 
elementFormDefault="qualified" attributeFormDefault="qualified" version=" 1 . 1 "> 
<xsd:annotation> 

<xsd:documentation> 

<version>l .0.0</version> 

<copyright>Copyright (c) 2005-2006 Mohamed Bishr, ITC, All Rights 

Reserved</copyright> 

</xsd:documentation> 
</xsd:annotation> 
<!-List Of Imports~> 

<xsd:import namespace="http://odrl.net/l. 1/ODRL-EX" schemaLocation="http://www.odrl.net/l. 1/ODRL-EX - 



<xsd:import namespace="http://odrl. net/1. 1/ODRL-DD" schemaLocation="http://www.odrl. net/1. 1/ODRL-DD- 



ll.xsd"/> 
ll.xsd"/> 

<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="C:\Documents and SettingsMVIohamed 
BishrVMy Documents\Msc thesis\Thesis\Chapter 5\GeoODRL\Base\feature.xsd"/> 

<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="C:\Documents and SettingsMVIohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\Base\coordinateReferenceSystems.xsd"/> 

<xsd:import namespace="http://www.in.tum.de/am" schemaLocation="C:\Documents and SettingsVMohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\CityModel\CityModel.xsd"/> 

<!-GRELSchema-> 

<!— declare new GeoREL datatypes— > 

<!-gml boundary to define the dataset boundaries in the context element of any entity specially asset entity— > 
<xsd:complexType name="gmlBoundary"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:contextType"> 
<xsd:sequence> 

<xsd:element name="DataSetBoundary" 

type="gml:BoundingShapeType" minOccurs="0"/> 

</xsd:sequence> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!— Defining this datatype makes it possible to specifiy application schema features in a rights expression n the 
context extity like in an asset element for exmaple— > 

<xsd:complexType name="gmlappSchema"> 
<xsd:annotation> 

<xsd:documentation> 
datatype is used to construct a context element of Type gmlAbstractFeatureType. 
</xsd:documentation> 

</xsd:annotation> 
<xsd:complexContent> 

<xsd:extension base="o-ex:contextType"> 
<xsd:choice> 

<xsd:element name= " app schemaElement" 

type="gmlAbstractFeatureType"/> 

</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd : complexTypo 

< [-define a datatype to be used to specify Coordinateoperation using a gml Type to make it possible to specify 
same operation defined in GML-> 
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<xsd:complexType name="CoordinateOperation"> 
<xsd : complexContent> 

<xsd:extension base="o-ex:permissionType"> 
<xsd:choice> 

<xsd:element name="coopID" type="gml:IdentifierType"/> 
</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!~deflne a datatype to be used to specify new requierements— > 
<xsd:complexType name="customerlicense"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:requirementType"> 
<xsd:choice> 

<xsd:element name="InternalBusinessUse" type="xsd:string" 

minOccurs="0"/> 

<xsd:element name="other" type="xsd:string" minOccurs="0"/> 
</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!— define new datatypes to be used for a specific variation of print constraints— > 
<xsd:complexType name="printResType"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:constraintType"> 

<xsd:attribute name="pRes" default="200dpi"> 
<xsd:simpleType> 

<xsd:restriction base="xsd:NMTOKEN"> 

<xsd:enumeration value="200dpi"/> 
<xsd:enumeration value="300dpi"/> 
<xsd:enumeration value="600dpi"/> 
<xsd:enumeration value="AH"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<xsd:complexType name="printPaperType"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:constraintType"> 

<xsd: attribute name="pSize" default="A4"> 
<xsd:simpleType> 

<xsd:restriction base="xsd:NMTOKEN"> 
<xsd:enumeration value="A6"/> 
<xsd:enumeration value="A5"/> 
<xsd: enumeration value='A4"/> 
<xsd: enumeration value='A3"/> 
<xsd:enumeration value='A2"/> 
<xsd:enumeration value='Al"/> 
<xsd:enumeration value='A0"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!— Declare New Requirement elements— > 

<xsd:element name="checkuserlicensetype" type="georel-dd:customerlicense" substitutionGroup="o- 
ex : requirementElement "/> 

<!— Declare New Permession elements— > 

<!— A permission to grant other permession as opposed to sell, move etc... — > 

<xsd:element name="regrant" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<xsd:element name="coordoperation" type="georel-dd:CoordinateOperation" substitutionGroup="o- 
ex:permissionElement"> 

<xsd:annotation> 
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<xsd:documentation>this element describes a coordinate operation permissions which uses 
gmkidentifierType to describe the operation name equivalent to the GML application schema</xsd:documentation> 
</xsd:annotation> 
</xsd:element> 

<xsd:element name="geometryconversion" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="qualitativeoperations" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="quantitativeoperations" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="newgeometry" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<xsd:element name="spatialoperator" type="o-ex:permissionType" substitutionGroup="o- 

ex:permissionElement"/> 

<xsd:element name="spatialrelation" type="o-ex:permissionType" substitutionGroup="o- 

ex:permissionElement"/> 

<xsd:element name="extractfeature" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<!-- Declare New Context elements-> 

<!- to decalre geometric boundaries within a given context specially in the asset element representing whole 

datasets-> 

<xsd:element name="Boundary" type="georel-dd:gmlBoundary" substitutionGroup="o-ex:contextElement"/> 
<xsd:element name="gmlfeature" type="georel-dd:gmlappSchema" substitutionGroup="o-ex:contextElement"/> 
<!— Declare new Constraint Elemnts— > 

<xsd:element name="printresolution" type="georel-dd:printResType" substitutionGroup="o- 
ex:constraintElement"/> 

<xsd:element name="papersize" type="georel-dd:printPaperType" substitutionGroup="o-ex:constraintElement"/> 
<!-- create new condition elements-> 

<!-- <xsd:element name="commercial " type="georel-dd:CoordinateOperation" substitutionGroup="o- 
ex:permissionElement"/>-> 
</xsd:schema> 
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Appendix (D): License Scenario 4.4.3 
XML instance 

■ The schema file supplied on CD with this thesis is Previewlicense.xml 

<?xml version="1.0" encoding="UTF-8"?> 

<!-- edited with XMLSpy v2006 spl U (http://www.altova.com) by Mohamed Bishr (EMBRACE) --> 
<!-- Mohamed Bishr All Rights Reserved 2006-3- 3-> 

<xsd:schema xmlns:xsd="http://www. w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml" xmlns:o- 
ex="http://odrl.net/l . 1/ODRL-EX" xmlns:o-dd="http://odrl.net/l . 1/ODRL-DD" xmlns:am="http://www.in.tum.de/am" 
xmlns:georel-dd="http://example.net/georel-dd" targetNamespace="http://example.net/georel-dd" 
elementFormDefault="qualified" attributeFormDefault="qualified" version=" 1 . 1 "> 
<xsd:annotation> 

<xsd:documentation> 

<version>l .0.0</version> 

<copyright>Copyright (c) 2005-2006 Mohamed Bishr, ITC, All Rights 

Reserved</copyright> 

</xsd:documentation> 
</xsd : annotation> 
<!-List Of Imports~> 

<xsd:import namespace="http://odrl. net/1. 1/ODRL-EX" schemaLocation="http://www.odrl.net/l. 1/ODRL-EX - 



<xsd:import namespace="http://odrl. net/1. 1/ODRL-DD" schemaLocation="http://www.odrl. net/1. 1/ODRL-DD- 



ll.xsd"/> 
ll.xsd"/> 

<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="C:\Documents and SettingsMvlohamed 
BishrMVly DocumentsMvlsc thesis\Thesis\Chapter 5\GeoODRL\Base\feature.xsd"/> 

<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="C:\Documents and SettingsMvlohamed 
BishrMvly DocumentsMvlsc thesis\Thesis\Chapter 5\GeoODRL\Base\coordinateReferenceSystems.xsd"/> 

<xsd:import namespace="http://www.in.tum.de/am" schemaLocation="C:\Documents and SettingsMvlohamed 
BishrVMy DocumentsMvlsc thesis\Thesis\Chapter 5\GeoODRL\CityModel\CityModel.xsd"/> 

<!-GRELSchema-> 

<!— declare new GeoREL datatypes— > 

<!— gml boundary to define the dataset boundaries in the context element of any entity specially asset entity— > 
<xsd:complexType name="gmlBoundary"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:contextType"> 
<xsd:sequence> 

<xsd:element name="DataSetBoundary" 

type="gml:BoundingShapeType" minOccurs="0"/> 

</xsd:sequence> 
</xsd:extension> 
</xsd:complexContent> 
</xsd : complexTypo 

<!— Defining this datatype makes it possible to specifiy application schema features in a rights expression n the 
context extity like in an asset element for exmaple— > 

<xsd:complexType name="gmlappSchema"> 
<xsd:annotation> 

<xsd:documentation> 
datatype is used to construct a context element of Type gmlAbstractFeatureType. 
</xsd:documentation> 

</xsd:annotation> 
<xsd:complexContent> 

<xsd:extension base="o-ex:contextType"> 
<xsd:choice> 

<xsd:element name="appschemaElement" 

type=" gml Ab stractFeatureType "/> 

</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd : complexTypo 

< [-define a datatype to be used to specify Coordinateoperation using a gml Type to make it possible to specify 
same operation defined in GML— > 

<xsd:complexType name="CoordinateOperation"> 
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<xsd:complexContent> 

<xsd:extension base="o-ex:permissionType"> 
<xsd:choice> 

<xsd:element name="coopID" type="gml:IdentifierType"/> 
</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

< [-define a datatype to be used to specify new requierements-> 
<xsd:complexType name="customerlicense"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:requirementType"> 
<xsd:choice> 

<xsd:element name="InternalBusinessUse" type="xsd:string" 

minOccurs="0"/> 

<xsd:element name="other" type="xsd:string" minOccurs="0"/> 
</xsd:choice> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!— define new datatypes to be used for a specific variation of print constraints— > 
<xsd:complexType name="printResType"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:constraintType"> 

<xsd:attribute name="pRes" default="200dpi"> 
<xsd:simpleType> 

<xsd:restriction base="xsd:NMTOKEN"> 

<xsd:enumeration value="200dpi"/> 
<xsd:enumeration value="300dpi"/> 
<xsd:enumeration value="600dpi"/> 
<xsd:enumeration value="AU"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<xsd:complexType name="printPaperType"> 
<xsd:complexContent> 

<xsd:extension base="o-ex:constraintType"> 

<xsd:attribute name="pSize" default="A4"> 
<xsd:simpleType> 

<xsd:restriction base="xsd:NMTOKEN"> 
<xsd:enumeration value="A6"/> 
<xsd:enumeration value="A5"/> 
<xsd:enumeration value='A4"/> 
<xsd: enumeration value='A3"/> 
<xsd:enumeration value='A2"/> 
<xsd:enumeration value='Al"/> 
<xsd:enumeration value='A0"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

<!— Declare New Requirement elements— > 

<xsd:element name="checkuserlicensetype" type="georel-dd:customerlicense" substitutionGroup="o- 
ex : requirementElement "/> 

<!— Declare New Permession elements— > 

<!— A permission to grant other permession as opposed to sell, move etc... — > 

<xsd:element name="regrant" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<xsd:element name="coordoperation" type="georel-dd:CoordinateOperation" substitutionGroup="o- 
ex:permissionElement"> 

<xsd:annotation> 
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<xsd:documentation>this element describes a coordinate operation permissions which uses 
gmkidentifierType to describe the operation name equivalent to the GML application schema</xsd:documentation> 
</xsd:annotation> 
</xsd:element> 

<xsd:element name="geometryconversion" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="qualitativeoperations" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="quantitativeoperations" type="o-ex:permissionType" substitutionGroup="o- 
ex:permissionElement"/> 

<xsd:element name="newgeometry" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<xsd:element name="spatialoperator" type="o-ex:permissionType" substitutionGroup="o- 

ex:permissionElement"/> 

<xsd:element name="spatialrelation" type="o-ex:permissionType" substitutionGroup="o- 

ex:permissionElement"/> 

<xsd:element name="extractfeature" type="o-ex:permissionType" substitutionGroup="o-ex:permissionElement"/> 
<!-- Declare New Context elements-> 

<!- to decalre geometric boundaries within a given context specially in the asset element representing whole 

datasets-> 

<xsd:element name="Boundary" type="georel-dd:gmlBoundary" substitutionGroup="o-ex:contextElement"/> 
<xsd:element name="gmlfeature" type="georel-dd:gmlappSchema" substitutionGroup="o-ex:contextElement"/> 
<!— Declare new Constraint Elemnts— > 

<xsd:element name="printresolution" type="georel-dd:printResType" substitutionGroup="o- 
ex:constraintElement"/> 

<xsd:element name="papersize" type="georel-dd:printPaperType" substitutionGroup="o-ex:constraintElement"/> 
<!-- create new condition elements-> 

<!-- <xsd:element name="commercial " type="georel-dd:CoordinateOperation" substitutionGroup="o- 
ex:permissionElement"/>-> 
</xsd:schema> 



GEOSPATIAL DIGITAL RIGHTS MANAGEMENT 



Appendix (E): City Model application 
schema 

The schema file supplied on CD with this thesis is Previewlicense.xml 

<?xml version="1.0" encoding="UTF-8"?> 

<schema xmlns="http://www.w3. org/200 1/XMLSchema" xmlns:am="http://www.in.tum.de/am" 
xmlns:gml="http://www.opengis.net/gml" xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" targetNamespace="http://www.in.tum.de/am" 
elementFormDefault="qualified"> 

<import namespace="http://www.opengis.net/gml" schemaLocation="C:\Documents and Settings\Mohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\Base\feature.xsd"/> 

<import namespace="http://www.w3.org/1999/xlink" schemaLocation="C:\Documents and SettingsVMohamed 
BishrVMy DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\xlink\xlinks.xsd"/> 

<element name="CityModel" type="am:CityModelType" substitutionGroup="gml:_FeatureCollection"/> 
<element name="Street" type="am:StreetType" substitutionGroup="gml:_Feature"/> 
<element name="Intersection" type="am:IntersectionType" substitutionGroup="gml:_Feature"/> 
<element name="Building" type="am:BuildingType" substitutionGroup="gml:_Feature"/> 
<complexType name="CityModelType"> 
<complexContent> 

<extension base="gml:AbstractFeatureCollectionType"/> 
</complexContent> 
</complexType> 

<complexType name="StreetType"> 
<complexContent> 

<extension base="gml:AbstractFeatureType"> 
<sequence minOccurs="0"> 

<element name="Name"/> 
<element ref="gml:LineString"/> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 

<complexType name="IntersectionType"> 
<complexContent> 

<extension base="gml:AbstractFeatureType"> 
<sequence minOccurs="0"> 

<element name="Name"/> 
<element ref="gml:Point"/> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 

<complexType name="BuildingType"> 
<complexContent> 

<extension base="gml:AbstractFeatureType"> 
<sequence minOccurs="0"> 

<element name="Address"/> 

<element name="Shape" type="gml:PolygonType"/> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 

</schema> 
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Appendix (F): City Model XML instance 

■ The schema file supplied on CD with this thesis is Previewlicense.xml 

<?xml version="1.0" encoding="UTF-8"?> 

<CityModel xmlns="http://www.in.tum.de/am" xmlns:xlink="http://www.w3. org/1 999/xlink" 
xmlns:gml="http://www.opengis.net/gml" xmlns:am="http://www.in.tum.de/am" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.in.tum.de/am C:\Documents 
and Settings\Mohamed Bishr\My DocumentsVMsc thesis\Thesis\Chapter 5\GeoODRL\CityModel\CityModel.xsd" 
fid="CityModel"> 

<gml:boundedBy> 

<gml:Box gid="boxl" srsName="foo"> 
<gml:coord> 

<gml:X>0</gml:X> 
<gml : Y>0</gml : Y> 
</gml:coord> 
<gml:coord> 

<gml : X>4</gml : X> 
<gml:Y>4</gml:Y> 
</gml:coord> 
</gml:Box> 
</gml : boundedB y > 
<gml:featureMember> 

<Intersection fid="Il"> 

<Name>Intersection A</Name> 
<gml:Point srsName="foo"> 
<gml:coord> 

<gml:X>0</gml:X> 
<gml:Y>0</gmlY> 
</gml:coord> 
</gml:Point> 
</Intersection> 
</gml : featureMember> 
<gml:featureMember> 

intersection fid="I2"> 

<Name>Intersection B</Name> 
<gml:Point srsName="foo"> 
<gml:coord> 

<gml:X>0</gml:X> 
<gml : Y>4</gml: Y> 
</gml:coord> 
</gml:Point> 
</Intersection> 
</gml : featureMember> 
<gml:featureMember> 

intersection fid="I3"> 

<Name>Intersection C</Name> 
<gml:Point srsName="foo"> 
<gml:coord> 

<gml:X>2</gml:X> 
<gml:Y>0</gmlY> 
</gml:coord> 
</gml:Point> 
</Intersection> 
</gml : featureMember> 
<gml:featureMember> 

intersection fid="I4"> 

<Name>Intersection D</Name> 
<gml:Point srsName="foo"> 
<gml:coord> 

<gml:X>2</gml:X> 
<gml : Y>4</gml: Y> 
</gml:coord> 
</gml:Point> 
</Intersection> 
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</gml : featureMember> 
<gml : f eatureMember> 

intersection fid="I5"> 

<Name>Intersection E</Name> 
<gml:Point srsName="foo"> 
<gml:coord> 

<gml:X>4</gml:X> 
<gml:Y>2</gml:Y> 
</gml:coord> 
</gml:Point> 
</Intersection> 
</gml : featureMember> 
<gml : f eatureMember> 

<Building xsi:type="BuildingType" fid="BuildingA"> 
<Address>Street A</Address> 
<Shape srsName="foo"> 

<gml:outerBoundaryIs> 

<gml:LinearRing> 

<gml:coord> 

<gml: X>- 1 </gml : X> 
<gml:Y>2</gml:Y> 



<gml: X>- 1 </gml : X> 
<gml:Y>2</gml:Y> 
</gml:coord> 
</gml:LinearRing> 
</gml : outerBoundaryIs> 

</Shape> 
</Building> 
</gml : featureMember> 
<gml : f eatureMember> 

<Building xsi:type="BuildingType" fid="BuildingB"> 
<Address>Street D</Address> 
<Shape srsName="foo"> 

<gml:outerBoundaryIs> 

<gml:LinearRing> 

<gml:coord> 

<gml:X>5</gml:X> 
<gml:Y>4</gml:Y> 



</gml:coord> 
<gml:coord> 

<gml: 
<gml: 
</gml:coord> 
<gml:coord> 

<gml: 
<gml: 
</gml:coord> 
<gml:coord> 

<gml: 
<gml: 
</gml:coord> 
<gml:coord> 



:X>-l</gml:X> 
:Y>3</gml:Y> 



:X>0</gml:X> 
:Y>3</gml:Y> 



:X>0</gml:X> 
:Y>2</gml:Y> 



</gml:coord> 
<gml:coord> 

<gml: 
<gml: 
</gml:coord> 
<gml:coord> 

<gml: 
<gml: 
</gml:coord> 
<gml:coord> 

<gml: 
<gml: 
</gml:coord> 
<gml:coord> 



:X>6</gml:X> 
:Y>4</gml:Y> 



:X>5</gml:X> 
:Y>5</gml:Y> 



:X>6</gml:X> 
:Y>5</gml:Y> 
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<gml : X>5 </gml : X> 
<gml: Y>4</gml: Y> 
</gml:coord> 
</gml:LinearRing> 
</gml:outerBoundaryIs> 

</Shape> 
</Building> 
</gml : featureMember> 
<gml:featureMember> 

<Streetfid="Sl"> 

<Name>Street A</Name> 
<gml:LineString> 

<gml:coord> 

<gml:X>0</gml:X> 
<gml:Y>0</gml:Y> 
</gml:coord> 
<gml:coord> 

<gml:X>0</gml:X> 
<gml : Y>4</gml: Y> 
</gml:coord> 
</gml:LineString> 

</Street> 
</gml : featureMember> 
<gml : f eatureMember> 

<Street fid="S2"> 

<Name>Street B</Name> 
<gml:LineString> 

<gml:coord> 

<gml:X>0</gml:X> 
<gml : Y>4</gml: Y> 
</gml:coord> 
<gml:coord> 

<gml:X>2</gml:X> 
<gml:Y>4</gml:Y> 
</gml:coord> 
</gml:LineString> 

</Street> 
</gml : featureMember> 
<gml : f eatureMember> 

<Streetfid="S3"> 

<Name>Street C</Name> 
<gml:LineString> 

<gml:coord> 

<gml:X>0</gml:X> 
<gml:Y>0</gml:Y> 
</gml:coord> 
<gml:coord> 

<gml:X>2</gml:X> 
<gml:Y>0</gml:Y> 
</gml:coord> 
</gml:LineString> 

</Street> 
</gml : featureMember> 
<gml : f eatureMember> 

<Street fid="S4"> 

<Name>Street D</Name> 
<gml:LineString> 

<gml:coord> 

<gml:X>2</gml:X> 
<gml : Y>4</gml: Y> 
</gml:coord> 
<gml:coord> 

<gml:X>4</gml:X> 
<gml:Y>2</gml:Y> 
</gml:coord> 
</gml:LineString> 
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</Street> 
</gml : featureMember> 
<gml:featureMember> 

<Street fid="S5"> 

<Name>Street E</Name> 
<gml:LineString> 

<gml:coord> 

<gml:X>2</gml:X> 
<gml:Y>0</gml:Y> 
</gml:coord> 
<gml:coord> 

<gml:X>4</gml:X> 
<gml:Y>2</gml:Y> 
</gml:coord> 
</gml:LineString> 

</Street> 
</gml : featureMember> 
</CityModel> 
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